Oscar, comments inline.=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In the last PCE meeting, it was mentioned by the WG chairs t= hat the function of LSP initiation by the PCE =A0(presented in the draft dr= aft-crabbe-pce-pce-initiated-lsp-00) is out of the scope of current WG charter. Current IETF stateful PCE draft () supports the function of de= legation, which is an operation to grant a PCE temporary rights to modify a= subset of tunnel parameters on one or more PCC's tunnels. However, cur= rent charter (http://datatracker.ietf.org/wg/pce/charter/) says nothing about this function, but the draft was (surprisingly) quickly= accepted as WG document. Current charter says =93The PCE Working Group is = chartered to specify the required protocols so as to enable a Path Computat= ion Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point t= o Multi-point Traffic Engineered LSPs.=94 That is =93computation=94, not co= ntrol=85 So,=A0 could you explain why initiation is not in charter and dele= gation of control is in charter?

IMO: they're the same thing, the= only difference is directionality and asynchrony.=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 My opinion in the matter of the stateful PCE is that we sho= uld separate the functionality is different functional elements, in the sam= e way as it was done in the Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In su= ch RFC, the roles of each functional element are clearly distinguished. Let= be the stateful PCE a Path Computation element using the traffic engineeri= ng database and the LSP database, and then, define another functional element (call it LSP controller, call = it manager) that is in care of the control issues.

This argument is orthogonal to the previous paragr= aph regarding the charter; =A0let's separate the two discussions. ;)

w/r/t *element* separation: I think that's a poor idea, sorry. =A0= It makes total sense to me that a given PCE would be able to negotiate and = support stateful or stateless functionality.=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Said that, I must say that I like the new functionalities p= roposed , and I think they solve problems (and people also did like them, a= s the stateful draft was supported by the WG people). What I do not like at all is how it is being handled. There has been a solution quickly = adopted without taking any care in the architectural/functional implication= s. In my opinion we should handle them now.

Define quickly man? =A0The original draft went through = multiple rounds of review both on list and in multiple (technically two but= really three) IETF meetings before acceptance. =A0It has received, as you = said, broad support and review by many people on the list, including you. ;= ) It is at a relatively low rev count and is still a work in progress. =A0 = =A0

=A0best,

=A0 -ed

--f46d044283d8d9e4d004cdefaad7-- From ogondio@tid.es Wed Nov 7 16:17:11 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB66421F8BE5 for ; Wed, 7 Nov 2012 16:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=-2.067, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ipScmbQH4ZDC for ; Wed, 7 Nov 2012 16:17:08 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 102E821F8BCD for ; Wed, 7 Nov 2012 16:16:58 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MD500KYP7G9BO@tid.hi.inet> for pce@ietf.org; Thu, 08 Nov 2012 01:16:57 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 0A.6F.05494.9F9FA905; Thu, 08 Nov 2012 01:16:57 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MD500KYL7G8BO@tid.hi.inet> for pce@ietf.org; Thu, 08 Nov 2012 01:16:57 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0318.004; Thu, 08 Nov 2012 01:16:56 +0100 Date: Thu, 08 Nov 2012 00:16:56 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: X-Originating-IP: [10.95.64.115] To: Edward Crabbe Message-id: <7CFF94B047D8864CB6268315034E35DE08A71B14@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_88J6Asltp6af9kohOKIxow)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-index: AQHNvTuDpy/jaqBHqkWZF3+0kk/IvpffBQsw X-AuditID: 0a5f4e69-b7fc06d000001576-c5-509af9f97c10 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXCFe9nqPvz56wAg76ZghZN92+wOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+2X/+wFMwor5h1/xNrA+DShi5GDQ0LARGLV06ouRk4gU0zi wr31bF2MXBxCAtsYJSZ+6mKCcL4xSnS0zmWGcKYxSjzedZARpIVFQFXi8a8VLCA2m4CDxLpF vWwgtrBAhsTE2bvZQWxOgWCJtnWLWCBWKEj8OfcYzBYRUJJY0H6dGeQKZgFFiXe3eUHCvALe EtP27mKHsAUlfky+B1bOLJArcajzHjuELS4x59dEVhCbUUBWYuX504wQIzMl3jS0MkHYRhIz Ny5gg1grILFkz3lmCFtU4uXjf6wQv0xilHg05xzbBEaxWUj2zUKybxaSfRC2nsSNqVPYIGxt iWULXzND2LoSM/4dYkEWX8DIvopRrDipKDM9oyQ3MTMn3cBILyNTLzMvtWQTIyTuMncwLt+p cohRgINRiYeXQ2ZWgBBrYllxZe4hRkkOJiVR3vffgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVE eKccAcrxpiRWVqUW5cOkZDg4lCR4hYEpQkiwKDU9tSItMweYXGDSTBycIO08QO2ff4C0Fxck 5hZnpkPkTzGqcuzcufAhoxBLXn5eqpQ47x6QIgGQoozSPLg5rxjFgQ4W5mUDWcMDTI9wE14B DWcCGl58bQbI8JJEhJRUA2PcWQM3W7XjDIqcYZtC2psUF/5p+J654mMib+jK9L7Ic85nHHr6 tngynut7cK2A9ZzKgTlr7N9MlproOzuzYYsk078LNx8Udd6Z+1P4qsriKoZ1zfO33Gm14P4R Lyjau9JrSrG9s2xF7/XwJabT3BY+mfG8Z03jk4WmCZXXKzm6Ys2bz8/d+02JpTgj0VCLuag4 EQBgUGvZTAMAAA== References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 00:17:12 -0000 --Boundary_(ID_88J6Asltp6af9kohOKIxow) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Ed, answers inline, IMO: they're the same thing, the only difference is directionality and asyn= chrony. [Oscar] Agree.. Let's see what our WG chairs say. My opinion in the matter of the stateful PCE is that we sho= uld separate the functionality is different functional elements, in the sam= e way as it was done in the Framework for PCE-Based Inter-Layer MPLS and GM= PLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In such RFC,= the roles of each functional element are clearly distinguished. Let be the= stateful PCE a Path Computation element using the traffic engineering data= base and the LSP database, and then, define another functional element (cal= l it LSP controller, call it manager) that is in care of the control issues= . This argument is orthogonal to the previous paragraph regarding the charter= ; let's separate the two discussions. ;) [Oscar] Agree, it's a separate discussion. w/r/t *element* separation: I think that's a poor idea, sorry. It makes to= tal sense to me that a given PCE would be able to negotiate and support sta= teful or stateless functionality. [Oscar] What I mean is to have a demarcation of the functional blocks. My p= roblem is that I may be too picky, but I like to call things by its name...= and for me still Path Computation refers to the computation function and n= ot controlling. So path computation and control of a delegated LSP (or even= initiation) are different functions, which are tightly connected to solve = the problems. I guess when you refer to negotiate "stateful" functionality = you are referring to negotiate the delegation+whatever control functionalit= ies and not only the fact of using (and synchronizing) the LSP Database. Th= e confusion may come from the fact you see the "stateful PCE" as the sum of= a controller + a PCE + TEDB+LSPDB.... I like that entity, but, strictly s= peaking, it is more than a PCE ...... But it is only a matter of naming, we= all have agreed that the functionality is needed, and that PCEP is a good = protocol to support it. I see this "controller" functional block as a generalization of the VNTM fu= nctional block defined in RFC 5623 for the specific case of controlling/man= aging an overlay network. Said that, I must say that I like the new functionalities p= roposed , and I think they solve problems (and people also did like them, a= s the stateful draft was supported by the WG people). What I do not like at= all is how it is being handled. There has been a solution quickly adopted = without taking any care in the architectural/functional implications. In my= opinion we should handle them now. Define quickly man? The original draft went through multiple rounds of rev= iew both on list and in multiple (technically two but really three) IETF me= etings before acceptance. It has received, as you said, broad support and review by many people on t= he list, including you. ;) It is at a relatively low rev count and is still= a work in progress. [Oscar] And I do support it and like it! I meant quickly because it went th= rough directly as a solution. Other pieces of work had to deal first with t= he framework/requirements and then jump in the solution, there are plenty o= f examples around, you can see the time of the first draft of the framework= /requirements and the time of the adoption of the first WG solution.... (In= terlayer, GMPLS, H-PCE)... This stateful PCE approach has a lot of implicat= ions, this is why I think we should take it with care and make it work toge= ther, with a clear architecture and make a good framework to have solid fou= ndations. best, -ed Best Regards, =D3scar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_88J6Asltp6af9kohOKIxow) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Ed, answers inline,<= /span>

IMO: they're the same thi= ng, the only difference is directionality and asynchrony.

[Oscar] = Agree.. Let’s see what our WG chairs say.

&n= bsp; My o= pinion in the matter of the stateful PCE is that we should separate the fun= ctionality is different functional elements, in the same way as it was done= in the Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. = In such RFC, the roles of each functional element are clearly distinguished= . Let be the stateful PCE a Path Computation element using the traffic engi= neering database and the LSP database, and then, define another functional element (call it LSP controller, call = it manager) that is in care of the control issues.

This argument is orthogonal to the previ= ous paragraph regarding the charter; let's separate the two discussio= ns. ;)

[Oscar] = Agree, it’s a separate discussion.

w/r/t *element* separatio= n: I think that's a poor idea, sorry. It makes tot= al sense to me that a given PCE would be able to negotiate and support stateful or sta= teless functionality.

[Oscar] = What I mean is to have a demarcation of the functional blocks. My problem i= s that I may be too picky, but I like to call things by its name… and for me still Path Computation refers to the computation fu= nction and not controlling. So path computation and control of a delegated = LSP (or even initiation) are different functions, which are tightly connect= ed to solve the problems. I guess when you refer to negotiate “stateful” functionality you are referr= ing to negotiate the delegation+whatever control functionalities and no= t only the fact of using (and synchronizing) the LSP Database. The confusio= n may come from the fact you see the “stateful PCE” as the sum of a controller + a PCE + TEDB+LSPDB…. = I like that entity, but, strictly speaking, it is more than a PCE …&#= 8230; But it is only a matter of naming, we all have agreed that the functi= onality is needed, and that PCEP is a good protocol to support it.

I see th= is “controller” functional block as a generalization of the VNT= M functional block defined in RFC 5623 for the specific case of controlling= /managing an overlay network.

&n= bsp; Said= that, I must say that I like the new functionalities proposed , and I thin= k they solve problems (and people also did like them, as the stateful draft= was supported by the WG people). What I do not like at all is how it is being handled. There has been a solution= quickly adopted without taking any care in the architectural/functional im= plications. In my opinion we should handle them now.

Define quickly man? The original d= raft went through multiple rounds of review both on list and in multiple (t= echnically two but really three) IETF meetings before acceptance.

It has received, as= you said, broad support and review by many people on the list, including y= ou. ;) It is at a relatively low rev count and is still a work in progress.

[Oscar] = And I do support it and like it! I meant quickly because it went through di= rectly as a solution. Other pieces of work had to deal first with the framework/requirements and then jump in the solution, there are p= lenty of examples around, you can see the time of the first draft of the fr= amework/requirements and the time of the adoption of the first WG solution&= #8230;. (Interlayer, GMPLS, H-PCE)… This stateful PCE approach has a lot of implications, this is why I think we sh= ould take it with care and make it work together, with a clear architecture= and make a good framework to have solid foundations.

best,

-ed

Best Regards,

= ; =D3scar=

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--Boundary_(ID_88J6Asltp6af9kohOKIxow)-- From zhangfatai@huawei.com Wed Nov 7 22:12:08 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D3C21F88D1 for ; Wed, 7 Nov 2012 22:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 FXxh7gY3wcit for ; Wed, 7 Nov 2012 22:12:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E67AD21F8546 for ; Wed, 7 Nov 2012 22:12:06 -0800 (PST) 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 AMN42542; Thu, 08 Nov 2012 06:12:04 +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; Thu, 8 Nov 2012 06:11:50 +0000 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 8 Nov 2012 06:12:03 +0000 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.134]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Thu, 8 Nov 2012 14:11:53 +0800 From: Fatai Zhang To: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= , Edward Crabbe Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: Ac29M0Ug4djLg+GXRUWVnAOlC+tbMP//iiUAgAAV7QD//xoXAA== Date: Thu, 8 Nov 2012 06:11:53 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <7CFF94B047D8864CB6268315034E35DE08A71B14@EX10-MB2-MAD.hi.inet> In-Reply-To: <7CFF94B047D8864CB6268315034E35DE08A71B14@EX10-MB2-MAD.hi.inet> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.85] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF82D686DAESZXEML552MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] =?utf-8?b?562U5aSNOiAgUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBD?= =?utf-8?q?E=2C_relation_to_WG_charter_and_opinion_about_stateful_PCE?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 06:12:09 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF82D686DAESZXEML552MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT3NjYXIsIEVkIGFuZCBhbGwsDQoNCkkgdG90YWxseSBhZ3JlZSB3aXRoIE9zY2FyLg0KDQpJ IHRoaW5rIHdlIHNob3VsZCBmb2xsb3cgdGhlIHJlZ3VsYXIgcHJvY2VkdXJlcyBvZiBQQ0UgV0cg KElFVEYgYXMgd2VsbCkgdG8gZGVmaW5lIHRoZSBmb3VuZGF0aW9uIHdvcmsgZmlyc3QgaW5jbHVk aW5nIEZXSywgcmVxdWlyZW1lbnQsIGFwcGxpY2FiaWxpdHkgYmVmb3JlIGRyb3BwaW5nIGludG8g dGhlIHNvbHV0aW9uIHN0dWZmLg0KDQpHdWlkYW5jZSBmcm9tIFdHIGNoYWlycyBvbiB0aGlzIHN0 YXRlZnVsIFBDRSB3b3JrIG11c3QgYmUgYXBwcmVjaWF0ZWQuDQoNCg0KQmVzdCBSZWdhcmRzDQoN CkZhdGFpDQoNCuWPkeS7tuS6ujogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91 bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE9zY2FyIEdvbnrDoWxleiBkZSBEaW9zDQrlj5HpgIHml7bp l7Q6IDIwMTLlubQxMeaciDjml6UgODoxNw0K5pS25Lu25Lq6OiBFZHdhcmQgQ3JhYmJlDQrmioTp gIE6IHBjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW1BjZV0gUXVlc3Rpb25zIGFib3V0IHN0YXRl ZnVsIFBDRSwgcmVsYXRpb24gdG8gV0cgY2hhcnRlciBhbmQgb3BpbmlvbiBhYm91dCBzdGF0ZWZ1 bCBQQ0UNCg0KSGkgRWQsIGFuc3dlcnMgaW5saW5lLA0KDQoNCklNTzogdGhleSdyZSB0aGUgc2Ft ZSB0aGluZywgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBkaXJlY3Rpb25hbGl0eSBhbmQgYXN5bmNo cm9ueS4NCltPc2Nhcl0gQWdyZWUuLiBMZXTigJlzIHNlZSB3aGF0IG91ciBXRyBjaGFpcnMgc2F5 Lg0KDQogICAgICAgICAgICAgICAgTXkgb3BpbmlvbiBpbiB0aGUgbWF0dGVyIG9mIHRoZSBzdGF0 ZWZ1bCBQQ0UgaXMgdGhhdCB3ZSBzaG91bGQgc2VwYXJhdGUgdGhlIGZ1bmN0aW9uYWxpdHkgaXMg ZGlmZmVyZW50IGZ1bmN0aW9uYWwgZWxlbWVudHMsIGluIHRoZSBzYW1lIHdheSBhcyBpdCB3YXMg ZG9uZSBpbiB0aGUgRnJhbWV3b3JrIGZvciBQQ0UtQmFzZWQgSW50ZXItTGF5ZXIgTVBMUyBhbmQg R01QTFMgVHJhZmZpYyBFbmdpbmVlcmluZyAoUkZDIDU2MjMpIGJldHdlZW4gYSBWTlRNIGFuZCB0 aGUgUENFLiBJbiBzdWNoIFJGQywgdGhlIHJvbGVzIG9mIGVhY2ggZnVuY3Rpb25hbCBlbGVtZW50 IGFyZSBjbGVhcmx5IGRpc3Rpbmd1aXNoZWQuIExldCBiZSB0aGUgc3RhdGVmdWwgUENFIGEgUGF0 aCBDb21wdXRhdGlvbiBlbGVtZW50IHVzaW5nIHRoZSB0cmFmZmljIGVuZ2luZWVyaW5nIGRhdGFi YXNlIGFuZCB0aGUgTFNQIGRhdGFiYXNlLCBhbmQgdGhlbiwgZGVmaW5lIGFub3RoZXIgZnVuY3Rp b25hbCBlbGVtZW50IChjYWxsIGl0IExTUCBjb250cm9sbGVyLCBjYWxsIGl0IG1hbmFnZXIpIHRo YXQgaXMgaW4gY2FyZSBvZiB0aGUgY29udHJvbCBpc3N1ZXMuDQoNClRoaXMgYXJndW1lbnQgaXMg b3J0aG9nb25hbCB0byB0aGUgcHJldmlvdXMgcGFyYWdyYXBoIHJlZ2FyZGluZyB0aGUgY2hhcnRl cjsgIGxldCdzIHNlcGFyYXRlIHRoZSB0d28gZGlzY3Vzc2lvbnMuIDspDQpbT3NjYXJdIEFncmVl LCBpdOKAmXMgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uLg0KDQp3L3IvdCAqZWxlbWVudCogc2VwYXJh dGlvbjogSSB0aGluayB0aGF0J3MgYSBwb29yIGlkZWEsIHNvcnJ5LiAgSXQgbWFrZXMgdG90YWwg c2Vuc2UgdG8gbWUgdGhhdCBhIGdpdmVuIFBDRSB3b3VsZCBiZSBhYmxlIHRvIG5lZ290aWF0ZSBh bmQgc3VwcG9ydCBzdGF0ZWZ1bCBvciBzdGF0ZWxlc3MgZnVuY3Rpb25hbGl0eS4NCltPc2Nhcl0g V2hhdCBJIG1lYW4gaXMgdG8gaGF2ZSBhIGRlbWFyY2F0aW9uIG9mIHRoZSBmdW5jdGlvbmFsIGJs b2Nrcy4gTXkgcHJvYmxlbSBpcyB0aGF0IEkgbWF5IGJlIHRvbyBwaWNreSwgYnV0IEkgbGlrZSB0 byBjYWxsIHRoaW5ncyBieSBpdHMgbmFtZeKApiBhbmQgZm9yIG1lIHN0aWxsIFBhdGggQ29tcHV0 YXRpb24gcmVmZXJzIHRvIHRoZSBjb21wdXRhdGlvbiBmdW5jdGlvbiBhbmQgbm90IGNvbnRyb2xs aW5nLiBTbyBwYXRoIGNvbXB1dGF0aW9uIGFuZCBjb250cm9sIG9mIGEgZGVsZWdhdGVkIExTUCAo b3IgZXZlbiBpbml0aWF0aW9uKSBhcmUgZGlmZmVyZW50IGZ1bmN0aW9ucywgd2hpY2ggYXJlIHRp Z2h0bHkgY29ubmVjdGVkIHRvIHNvbHZlIHRoZSBwcm9ibGVtcy4gSSBndWVzcyB3aGVuIHlvdSBy ZWZlciB0byBuZWdvdGlhdGUg4oCcc3RhdGVmdWzigJ0gZnVuY3Rpb25hbGl0eSB5b3UgYXJlIHJl ZmVycmluZyB0byBuZWdvdGlhdGUgdGhlIGRlbGVnYXRpb24rd2hhdGV2ZXIgY29udHJvbCBmdW5j dGlvbmFsaXRpZXMgYW5kIG5vdCBvbmx5IHRoZSBmYWN0IG9mIHVzaW5nIChhbmQgc3luY2hyb25p emluZykgdGhlIExTUCBEYXRhYmFzZS4gVGhlIGNvbmZ1c2lvbiBtYXkgY29tZSBmcm9tIHRoZSBm YWN0IHlvdSBzZWUgdGhlIOKAnHN0YXRlZnVsIFBDReKAnSBhcyB0aGUgc3VtIG9mIGEgY29udHJv bGxlciArIGEgUENFICsgVEVEQitMU1BEQuKApi4gIEkgbGlrZSB0aGF0IGVudGl0eSwgYnV0LCBz dHJpY3RseSBzcGVha2luZywgaXQgaXMgbW9yZSB0aGFuIGEgUENFIOKApuKApiBCdXQgaXQgaXMg b25seSBhIG1hdHRlciBvZiBuYW1pbmcsIHdlIGFsbCBoYXZlIGFncmVlZCB0aGF0IHRoZSBmdW5j dGlvbmFsaXR5IGlzIG5lZWRlZCwgYW5kIHRoYXQgUENFUCBpcyBhIGdvb2QgcHJvdG9jb2wgdG8g c3VwcG9ydCBpdC4NCkkgc2VlIHRoaXMg4oCcY29udHJvbGxlcuKAnSBmdW5jdGlvbmFsIGJsb2Nr IGFzIGEgZ2VuZXJhbGl6YXRpb24gb2YgdGhlIFZOVE0gZnVuY3Rpb25hbCBibG9jayBkZWZpbmVk IGluIFJGQyA1NjIzIGZvciB0aGUgc3BlY2lmaWMgY2FzZSBvZiBjb250cm9sbGluZy9tYW5hZ2lu ZyBhbiBvdmVybGF5IG5ldHdvcmsuDQoNCiAgICAgICAgICAgICAgICBTYWlkIHRoYXQsIEkgbXVz dCBzYXkgdGhhdCBJIGxpa2UgdGhlIG5ldyBmdW5jdGlvbmFsaXRpZXMgcHJvcG9zZWQgLCBhbmQg SSB0aGluayB0aGV5IHNvbHZlIHByb2JsZW1zIChhbmQgcGVvcGxlIGFsc28gZGlkIGxpa2UgdGhl bSwgYXMgdGhlIHN0YXRlZnVsIGRyYWZ0IHdhcyBzdXBwb3J0ZWQgYnkgdGhlIFdHIHBlb3BsZSku IFdoYXQgSSBkbyBub3QgbGlrZSBhdCBhbGwgaXMgaG93IGl0IGlzIGJlaW5nIGhhbmRsZWQuIFRo ZXJlIGhhcyBiZWVuIGEgc29sdXRpb24gcXVpY2tseSBhZG9wdGVkIHdpdGhvdXQgdGFraW5nIGFu eSBjYXJlIGluIHRoZSBhcmNoaXRlY3R1cmFsL2Z1bmN0aW9uYWwgaW1wbGljYXRpb25zLiBJbiBt eSBvcGluaW9uIHdlIHNob3VsZCBoYW5kbGUgdGhlbSBub3cuDQoNCkRlZmluZSBxdWlja2x5IG1h bj8gIFRoZSBvcmlnaW5hbCBkcmFmdCB3ZW50IHRocm91Z2ggbXVsdGlwbGUgcm91bmRzIG9mIHJl dmlldyBib3RoIG9uIGxpc3QgYW5kIGluIG11bHRpcGxlICh0ZWNobmljYWxseSB0d28gYnV0IHJl YWxseSB0aHJlZSkgSUVURiBtZWV0aW5ncyBiZWZvcmUgYWNjZXB0YW5jZS4NCiBJdCBoYXMgcmVj ZWl2ZWQsIGFzIHlvdSBzYWlkLCBicm9hZCBzdXBwb3J0IGFuZCByZXZpZXcgYnkgbWFueSBwZW9w bGUgb24gdGhlIGxpc3QsIGluY2x1ZGluZyB5b3UuIDspIEl0IGlzIGF0IGEgcmVsYXRpdmVseSBs b3cgcmV2IGNvdW50IGFuZCBpcyBzdGlsbCBhIHdvcmsgaW4gcHJvZ3Jlc3MuDQpbT3NjYXJdIEFu ZCBJIGRvIHN1cHBvcnQgaXQgYW5kIGxpa2UgaXQhIEkgbWVhbnQgcXVpY2tseSBiZWNhdXNlIGl0 IHdlbnQgdGhyb3VnaCBkaXJlY3RseSBhcyBhIHNvbHV0aW9uLiBPdGhlciBwaWVjZXMgb2Ygd29y ayBoYWQgdG8gZGVhbCBmaXJzdCB3aXRoIHRoZSBmcmFtZXdvcmsvcmVxdWlyZW1lbnRzIGFuZCB0 aGVuIGp1bXAgaW4gdGhlIHNvbHV0aW9uLCB0aGVyZSBhcmUgcGxlbnR5IG9mIGV4YW1wbGVzIGFy b3VuZCwgeW91IGNhbiBzZWUgdGhlIHRpbWUgb2YgdGhlIGZpcnN0IGRyYWZ0IG9mIHRoZSBmcmFt ZXdvcmsvcmVxdWlyZW1lbnRzIGFuZCB0aGUgdGltZSBvZiB0aGUgYWRvcHRpb24gb2YgdGhlIGZp cnN0IFdHIHNvbHV0aW9u4oCmLiAoSW50ZXJsYXllciwgR01QTFMsIEgtUENFKeKApiBUaGlzIHN0 YXRlZnVsIFBDRSBhcHByb2FjaCBoYXMgYSBsb3Qgb2YgaW1wbGljYXRpb25zLCB0aGlzIGlzIHdo eSBJIHRoaW5rIHdlIHNob3VsZCB0YWtlIGl0IHdpdGggY2FyZSBhbmQgbWFrZSBpdCB3b3JrIHRv Z2V0aGVyLCB3aXRoIGEgY2xlYXIgYXJjaGl0ZWN0dXJlIGFuZCBtYWtlIGEgZ29vZCBmcmFtZXdv cmsgdG8gaGF2ZSBzb2xpZCBmb3VuZGF0aW9ucy4NCg0KIGJlc3QsDQogIC1lZA0KDQpCZXN0IFJl Z2FyZHMsDQoNCiAgICAgICAgICAgICAgICDDk3NjYXINCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1 IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOt byB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFk byBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBp dHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lz IG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9k aXNjbGFpbWVyLmFzcHgNCg== --_000_F82A4B6D50F9464B8EBA55651F541CF82D686DAESZXEML552MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVmYXVs dCwgZGl2Lm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVsdDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5lc3RpbG9jb3JyZW8x Nw0KCXttc28tc3R5bGUtbmFtZTplc3RpbG9jb3JyZW8xNzsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBPc2Nhciwg RWQgYW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0b3RhbGx5 IGFncmVlIHdpdGggT3NjYXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB0aGluayB3ZSBzaG91bGQgZm9sbG93IHRoZSByZWd1bGFyIHByb2NlZHVyZXMgb2YgUENFIFdH IChJRVRGIGFzIHdlbGwpIHRvIGRlZmluZSB0aGUgZm91bmRhdGlvbiB3b3JrIGZpcnN0IGluY2x1 ZGluZyBGV0ssIHJlcXVpcmVtZW50LCBhcHBsaWNhYmlsaXR5DQogYmVmb3JlIGRyb3BwaW5nIGlu dG8gdGhlIHNvbHV0aW9uIHN0dWZmLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlk ZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5HdWlkYW5jZSBmcm9tIFdHIGNoYWlycyBvbiB0aGlzIHN0YXRlZnVsIFBDRSB3b3Jr IG11c3QgYmUgYXBwcmVjaWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRl b2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdh cmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GYXRhaTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L 5L2TIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMi PiBwY2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBjZS1ib3VuY2VzQGlldGYub3JnXQ0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+ 5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+T3NjYXIgR29uejwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPsOhPHNwYW4gbGFuZz0iRU4tVVMiPmxl eiBkZSBEaW9zPGJyPg0KPC9zcGFuPjxiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDIwMTI8L3NwYW4+5bm0PHNwYW4gbGFuZz0i RU4tVVMiPjExPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj44PC9zcGFuPuaXpTxzcGFuIGxh bmc9IkVOLVVTIj4gODoxNzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBFZHdhcmQgQ3JhYmJlPGJyPg0KPC9z cGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IHBjZUBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW1BjZV0gUXVlc3Rpb25zIGFi b3V0IHN0YXRlZnVsIFBDRSwgcmVsYXRpb24gdG8gV0cgY2hhcnRlciBhbmQgb3BpbmlvbiBhYm91 dCBzdGF0ZWZ1bCBQQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBFZCwgYW5zd2VycyBp bmxpbmUsPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SU1POiB0aGV5J3JlIHRoZSBzYW1lIHRo aW5nLCB0aGUgb25seSBkaWZmZXJlbmNlIGlzIGRpcmVjdGlvbmFsaXR5IGFuZCBhc3luY2hyb255 LiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bT3NjYXJdIEFncmVlLi4gTGV04oCZcyBzZWUgd2hhdCBvdXIgV0cg Y2hhaXJzIHNheS48L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNeSBvcGluaW9uIGluIHRo ZSBtYXR0ZXIgb2YgdGhlIHN0YXRlZnVsIFBDRSBpcyB0aGF0IHdlIHNob3VsZCBzZXBhcmF0ZSB0 aGUgZnVuY3Rpb25hbGl0eSBpcyBkaWZmZXJlbnQgZnVuY3Rpb25hbCBlbGVtZW50cywgaW4gdGhl IHNhbWUgd2F5IGFzIGl0IHdhcyBkb25lIGluIHRoZSBGcmFtZXdvcmsgZm9yIFBDRS1CYXNlZCBJ bnRlci1MYXllciBNUExTDQogYW5kIEdNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcgKFJGQyA1NjIz KSBiZXR3ZWVuIGEgVk5UTSBhbmQgdGhlIFBDRS4gSW4gc3VjaCBSRkMsIHRoZSByb2xlcyBvZiBl YWNoIGZ1bmN0aW9uYWwgZWxlbWVudCBhcmUgY2xlYXJseSBkaXN0aW5ndWlzaGVkLiBMZXQgYmUg dGhlIHN0YXRlZnVsIFBDRSBhIFBhdGggQ29tcHV0YXRpb24gZWxlbWVudCB1c2luZyB0aGUgdHJh ZmZpYyBlbmdpbmVlcmluZyBkYXRhYmFzZSBhbmQgdGhlIExTUCBkYXRhYmFzZSwNCiBhbmQgdGhl biwgZGVmaW5lIGFub3RoZXIgZnVuY3Rpb25hbCBlbGVtZW50IChjYWxsIGl0IExTUCBjb250cm9s bGVyLCBjYWxsIGl0IG1hbmFnZXIpIHRoYXQgaXMgaW4gY2FyZSBvZiB0aGUgY29udHJvbCBpc3N1 ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBhcmd1bWVudCBpcyBvcnRo b2dvbmFsIHRvIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGggcmVnYXJkaW5nIHRoZSBjaGFydGVyOyAm bmJzcDtsZXQncyBzZXBhcmF0ZSB0aGUgdHdvIGRpc2N1c3Npb25zLiA7KTwvc3Bhbj48c3BhbiBs YW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bT3Nj YXJdIEFncmVlLCBpdOKAmXMgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uLjwvc3Bhbj48c3BhbiBsYW5n PSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij53L3IvdCAqZWxlbWVudCogc2VwYXJhdGlvbjogSSB0aGluayB0aGF0J3MgYSBwb29y IGlkZWEsIHNvcnJ5LiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkl0IG1ha2VzIHRvdGFsDQogc2Vuc2UgdG8gbWUgdGhhdCBhIGdpdmVuIFBDRSB3b3Vs ZCBiZSBhYmxlIHRvIG5lZ290aWF0ZSBhbmQgc3VwcG9ydCBzdGF0ZWZ1bCBvciBzdGF0ZWxlc3Mg ZnVuY3Rpb25hbGl0eS4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W09zY2FyXSBXaGF0IEkgbWVhbiBpcyB0byBo YXZlIGEgZGVtYXJjYXRpb24gb2YgdGhlIGZ1bmN0aW9uYWwgYmxvY2tzLiBNeSBwcm9ibGVtIGlz IHRoYXQgSSBtYXkgYmUgdG9vIHBpY2t5LCBidXQgSSBsaWtlIHRvIGNhbGwgdGhpbmdzIGJ5IGl0 cw0KIG5hbWXigKYgYW5kIGZvciBtZSBzdGlsbCBQYXRoIENvbXB1dGF0aW9uIHJlZmVycyB0byB0 aGUgY29tcHV0YXRpb24gZnVuY3Rpb24gYW5kIG5vdCBjb250cm9sbGluZy4gU28gcGF0aCBjb21w dXRhdGlvbiBhbmQgY29udHJvbCBvZiBhIGRlbGVnYXRlZCBMU1AgKG9yIGV2ZW4gaW5pdGlhdGlv bikgYXJlIGRpZmZlcmVudCBmdW5jdGlvbnMsIHdoaWNoIGFyZSB0aWdodGx5IGNvbm5lY3RlZCB0 byBzb2x2ZSB0aGUgcHJvYmxlbXMuIEkgZ3Vlc3Mgd2hlbg0KIHlvdSByZWZlciB0byBuZWdvdGlh dGUg4oCcc3RhdGVmdWzigJ0gZnVuY3Rpb25hbGl0eSB5b3UgYXJlIHJlZmVycmluZyB0byBuZWdv dGlhdGUgdGhlIGRlbGVnYXRpb24mIzQzO3doYXRldmVyIGNvbnRyb2wgZnVuY3Rpb25hbGl0aWVz IGFuZCBub3Qgb25seSB0aGUgZmFjdCBvZiB1c2luZyAoYW5kIHN5bmNocm9uaXppbmcpIHRoZSBM U1AgRGF0YWJhc2UuIFRoZSBjb25mdXNpb24gbWF5IGNvbWUgZnJvbSB0aGUgZmFjdCB5b3Ugc2Vl IHRoZSDigJxzdGF0ZWZ1bCBQQ0XigJ0NCiBhcyB0aGUgc3VtIG9mIGEgY29udHJvbGxlciAmIzQz OyBhIFBDRSAmIzQzOyBURURCJiM0MztMU1BEQuKApi4gJm5ic3A7SSBsaWtlIHRoYXQgZW50aXR5 LCBidXQsIHN0cmljdGx5IHNwZWFraW5nLCBpdCBpcyBtb3JlIHRoYW4gYSBQQ0Ug4oCm4oCmIEJ1 dCBpdCBpcyBvbmx5IGEgbWF0dGVyIG9mIG5hbWluZywgd2UgYWxsIGhhdmUgYWdyZWVkIHRoYXQg dGhlIGZ1bmN0aW9uYWxpdHkgaXMgbmVlZGVkLCBhbmQgdGhhdCBQQ0VQIGlzIGEgZ29vZCBwcm90 b2NvbCB0byBzdXBwb3J0IGl0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHNlZSB0aGlzIOKAnGNvbnRyb2xsZXLigJ0g ZnVuY3Rpb25hbCBibG9jayBhcyBhIGdlbmVyYWxpemF0aW9uIG9mIHRoZSBWTlRNIGZ1bmN0aW9u YWwgYmxvY2sgZGVmaW5lZCBpbiBSRkMgNTYyMyBmb3IgdGhlIHNwZWNpZmljIGNhc2Ugb2YgY29u dHJvbGxpbmcvbWFuYWdpbmcNCiBhbiBvdmVybGF5IG5ldHdvcmsuPC9zcGFuPjxzcGFuIGxhbmc9 IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU2FpZCB0aGF0LCBJIG11c3Qgc2F5IHRoYXQgSSBsaWtlIHRoZSBuZXcgZnVu Y3Rpb25hbGl0aWVzIHByb3Bvc2VkICwgYW5kIEkgdGhpbmsgdGhleSBzb2x2ZSBwcm9ibGVtcyAo YW5kIHBlb3BsZSBhbHNvIGRpZCBsaWtlIHRoZW0sIGFzIHRoZSBzdGF0ZWZ1bCBkcmFmdCB3YXMg c3VwcG9ydGVkIGJ5IHRoZSBXRyBwZW9wbGUpLiBXaGF0IEkgZG8gbm90DQogbGlrZSBhdCBhbGwg aXMgaG93IGl0IGlzIGJlaW5nIGhhbmRsZWQuIFRoZXJlIGhhcyBiZWVuIGEgc29sdXRpb24gcXVp Y2tseSBhZG9wdGVkIHdpdGhvdXQgdGFraW5nIGFueSBjYXJlIGluIHRoZSBhcmNoaXRlY3R1cmFs L2Z1bmN0aW9uYWwgaW1wbGljYXRpb25zLiBJbiBteSBvcGluaW9uIHdlIHNob3VsZCBoYW5kbGUg dGhlbSBub3cuPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGVmaW5lIHF1aWNrbHkg bWFuPyAmbmJzcDtUaGUgb3JpZ2luYWwgZHJhZnQgd2VudCB0aHJvdWdoIG11bHRpcGxlIHJvdW5k cyBvZiByZXZpZXcgYm90aCBvbiBsaXN0IGFuZCBpbiBtdWx0aXBsZSAodGVjaG5pY2FsbHkgdHdv IGJ1dCByZWFsbHkgdGhyZWUpIElFVEYgbWVldGluZ3MgYmVmb3JlDQogYWNjZXB0YW5jZS4gPC9z cGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7SXQg aGFzIHJlY2VpdmVkLCBhcyB5b3Ugc2FpZCwgYnJvYWQgc3VwcG9ydCBhbmQgcmV2aWV3IGJ5IG1h bnkgcGVvcGxlIG9uIHRoZSBsaXN0LCBpbmNsdWRpbmcgeW91LiA7KSBJdCBpcyBhdCBhIHJlbGF0 aXZlbHkgbG93IHJldiBjb3VudCBhbmQgaXMgc3RpbGwgYSB3b3JrIGluDQogcHJvZ3Jlc3MuICZu YnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W09zY2FyXSBBbmQgSSBkbyBzdXBwb3J0IGl0IGFuZCBsaWtl IGl0ISBJIG1lYW50IHF1aWNrbHkgYmVjYXVzZSBpdCB3ZW50IHRocm91Z2ggZGlyZWN0bHkgYXMg YSBzb2x1dGlvbi4gT3RoZXIgcGllY2VzIG9mIHdvcmsgaGFkIHRvIGRlYWwgZmlyc3QNCiB3aXRo IHRoZSBmcmFtZXdvcmsvcmVxdWlyZW1lbnRzIGFuZCB0aGVuIGp1bXAgaW4gdGhlIHNvbHV0aW9u LCB0aGVyZSBhcmUgcGxlbnR5IG9mIGV4YW1wbGVzIGFyb3VuZCwgeW91IGNhbiBzZWUgdGhlIHRp bWUgb2YgdGhlIGZpcnN0IGRyYWZ0IG9mIHRoZSBmcmFtZXdvcmsvcmVxdWlyZW1lbnRzIGFuZCB0 aGUgdGltZSBvZiB0aGUgYWRvcHRpb24gb2YgdGhlIGZpcnN0IFdHIHNvbHV0aW9u4oCmLiAoSW50 ZXJsYXllciwgR01QTFMsIEgtUENFKeKApiBUaGlzDQogc3RhdGVmdWwgUENFIGFwcHJvYWNoIGhh cyBhIGxvdCBvZiBpbXBsaWNhdGlvbnMsIHRoaXMgaXMgd2h5IEkgdGhpbmsgd2Ugc2hvdWxkIHRh a2UgaXQgd2l0aCBjYXJlIGFuZCBtYWtlIGl0IHdvcmsgdG9nZXRoZXIsIHdpdGggYSBjbGVhciBh cmNoaXRlY3R1cmUgYW5kIG1ha2UgYSBnb29kIGZyYW1ld29yayB0byBoYXZlIHNvbGlkIGZvdW5k YXRpb25zLjwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YmVzdCw8L3NwYW4+PHNwYW4gbGFuZz0iRVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgLWVkPC9zcGFuPjxzcGFu IGxhbmc9IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgw5NzY2FyPC9zcGFuPjxzcGFuIGxhbmc9IkVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlciI+PHNwYW4gbGFuZz0iRVMiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Z3JheSI+PGJyPg0KRXN0ZSBtZW5zYWplIHNl IGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFy IG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0 csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLjxicj4NClRoaXMgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5k IGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDo8 YnI+DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweDwvc3Bhbj48 c3BhbiBsYW5nPSJFUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_F82A4B6D50F9464B8EBA55651F541CF82D686DAESZXEML552MBSchi_-- From edc@google.com Wed Nov 7 23:57:53 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4824221F88B1 for ; Wed, 7 Nov 2012 23:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[AWL=-2.576, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, 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 7D96-81tH5F1 for ; Wed, 7 Nov 2012 23:57:52 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C153821F889E for ; Wed, 7 Nov 2012 23:57:51 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so1133059wgb.13 for ; Wed, 07 Nov 2012 23:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Lfq/2MyYSu4oJLIb0j3JiGsbqG1OpvXrKoEdYUQaErU=; b=Z2z5jRs/fdgWqfeImld7ibND/SpUAqeQd53SThG+oF0xbX9bifAPSoSXggSA06fAr6 57NVK9VEtbDvhmUapRUBUWHdVgt4DvGCiK2Kp8kd1DcojiyDBxuQBQX4D10tqjEqcL41 EQn02BXSV5+b5wFbcrB1s1C29WkDYuKZtokXBgIoH3IPVkVo/YW/jyt92uu6dcQpKlJz RVmvKV7Fu2OB5Qr3uW2Av+NHOUD4pOTFmbOoQtClWBZ4GRxs2GhiBm9dVBvsSTo03PdL zwLbjN4QZTn0QCaOfA1zA4jAtaaNmOmexRATJk3bkrcPUGxJXTZ9cZ05WI3YRgOBdDKf qOZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Lfq/2MyYSu4oJLIb0j3JiGsbqG1OpvXrKoEdYUQaErU=; b=mq+r2mPVdKCbxvvx60iPXZMUr7h7g+u+c+cL+q2iLoGKi/vAvKvEOSwnAlIkP+PKoL Yemr9QFz9JBuXvLeO7zgiQNeQSeLO2X3qUeoLd/k7mXx9FC13URVMszNe+JLREyGf8d2 6qmutvlAjRynyDAO50nYvZztezRtyOtjDz8Nq3bSHraEiyBFHXoB8xb1fkrMAQianSAx ZhD4I07UqlGE2AhY3clkhAeLRxSFEem1y9jdKR8zrmFb+o3s6HwDN9uBOS3A2NN3roTZ UVNHtc+LtT8vt3OYh2zw40GwXZscscshkV95hIvDoQC65j9dS+4cIZryUVFHhLaG1r2a ycRA== Received: by 10.181.11.163 with SMTP id ej3mr11655386wid.11.1352361470612; Wed, 07 Nov 2012 23:57:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.55.132 with HTTP; Wed, 7 Nov 2012 23:57:10 -0800 (PST) In-Reply-To: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <7CFF94B047D8864CB6268315034E35DE08A71B14@EX10-MB2-MAD.hi.inet> From: Edward Crabbe Date: Thu, 8 Nov 2012 02:57:10 -0500 Message-ID: To: Fatai Zhang Content-Type: multipart/alternative; boundary=f46d043be1e010534504cdf731af X-Gm-Message-State: ALoCoQlJBWd2o2G8ySqz9nKDYEhPVIenSSHO/KegvJ4iHYCn81ydYpkSNrnL7RynS+UFAV02f8kYgak6tgL2wqTL79TvRAB7EUvRCWKWpYAUViyA/HIJ8vrgs7L/oLiXGpDLdJubLnf6Scz/KsTFI/gv+XfoBszRxm0tbdrP+Fia3RMmiYyMt1Ln4FFH6b/miFZERidI8Mz/ Cc: "pce@ietf.org" Subject: Re: [Pce] =?utf-8?b?562U5aSNOiAgUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBD?= =?utf-8?q?E=2C_relation_to_WG_charter_and_opinion_about_stateful_P?= =?utf-8?q?CE?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 07:57:53 -0000 --f46d043be1e010534504cdf731af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIK: (a): we are getting guidance from the chairs on an ongoing basis and (b): the solution and framework are coupled and are reasonably well defined currently, modulo the (largely aesthetic) considerations raised On Thu, Nov 8, 2012 at 1:11 AM, Fatai Zhang wrote: > Hi Oscar, Ed and all,**** > > ** ** > > I totally agree with Oscar. **** > > ** ** > > I think we should follow the regular procedures of PCE WG (IETF as well) > to define the foundation work first including FWK, requirement, > applicability before dropping into the solution stuff. **** > > ** ** > > Guidance from WG chairs on this stateful PCE work must be appreciated.***= * > > ** ** > > ** ** > > Best Regards**** > > ** ** > > Fatai**** > > ** ** > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* pce-bounces@ietf.org [mailto:pce-bounces@i= etf.org] *=E4=BB=A3=E8=A1=A8 *Oscar Gonz=C3=A1lez > de Dios > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2012=E5=B9=B411=E6=9C=888=E6=97= =A5 8:17 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Edward Crabbe > *=E6=8A=84=E9=80=81:* pce@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [Pce] Questions about stateful PCE, relation to= WG charter and > opinion about stateful PCE**** > > ** ** > > Hi Ed, answers inline,**** > > **** > > **** > > IMO: they're the same thing, the only difference is directionality and > asynchrony. **** > > [Oscar] Agree.. Let=E2=80=99s see what our WG chairs say.**** > > **** > > My opinion in the matter of the stateful PCE is that we > should separate the functionality is different functional elements, in th= e > same way as it was done in the Framework for PCE-Based Inter-Layer MPLS a= nd > GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In such > RFC, the roles of each functional element are clearly distinguished. Let = be > the stateful PCE a Path Computation element using the traffic engineering > database and the LSP database, and then, define another functional elemen= t > (call it LSP controller, call it manager) that is in care of the control > issues.**** > > **** > > This argument is orthogonal to the previous paragraph regarding the > charter; let's separate the two discussions. ;)**** > > [Oscar] Agree, it=E2=80=99s a separate discussion.**** > > **** > > w/r/t *element* separation: I think that's a poor idea, sorry. It makes > total sense to me that a given PCE would be able to negotiate and support > stateful or stateless functionality. **** > > [Oscar] What I mean is to have a demarcation of the functional blocks. My > problem is that I may be too picky, but I like to call things by its name= =E2=80=A6 > and for me still Path Computation refers to the computation function and > not controlling. So path computation and control of a delegated LSP (or > even initiation) are different functions, which are tightly connected to > solve the problems. I guess when you refer to negotiate =E2=80=9Cstateful= =E2=80=9D > functionality you are referring to negotiate the delegation+whatever > control functionalities and not only the fact of using (and synchronizing= ) > the LSP Database. The confusion may come from the fact you see the > =E2=80=9Cstateful PCE=E2=80=9D as the sum of a controller + a PCE + TEDB+= LSPDB=E2=80=A6. I like > that entity, but, strictly speaking, it is more than a PCE =E2=80=A6=E2= =80=A6 But it is > only a matter of naming, we all have agreed that the functionality is > needed, and that PCEP is a good protocol to support it.**** > > I see this =E2=80=9Ccontroller=E2=80=9D functional block as a generalizat= ion of the VNTM > functional block defined in RFC 5623 for the specific case of > controlling/managing an overlay network.**** > > **** > > Said that, I must say that I like the new > functionalities proposed , and I think they solve problems (and people al= so > did like them, as the stateful draft was supported by the WG people). Wha= t > I do not like at all is how it is being handled. There has been a solutio= n > quickly adopted without taking any care in the architectural/functional > implications. In my opinion we should handle them now.**** > > **** > > Define quickly man? The original draft went through multiple rounds of > review both on list and in multiple (technically two but really three) IE= TF > meetings before acceptance. **** > > It has received, as you said, broad support and review by many people on > the list, including you. ;) It is at a relatively low rev count and is > still a work in progress. **** > > [Oscar] And I do support it and like it! I meant quickly because it went > through directly as a solution. Other pieces of work had to deal first wi= th > the framework/requirements and then jump in the solution, there are plent= y > of examples around, you can see the time of the first draft of the > framework/requirements and the time of the adoption of the first WG > solution=E2=80=A6. (Interlayer, GMPLS, H-PCE)=E2=80=A6 This stateful PCE = approach has a lot > of implications, this is why I think we should take it with care and make > it work together, with a clear architecture and make a good framework to > have solid foundations.**** > > **** > > best,**** > > -ed**** > > **** > > Best Regards,**** > > **** > > =C3=93scar**** > > ** ** > ------------------------------ > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3= =B3nico en el enlace > situado m=C3=A1s abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx**** > --f46d043be1e010534504cdf731af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

AFAIK:=

(a): we are getting guidance from the chairs on an ongo= ing basis and

(b): the solution and framework are coupled and are= reasonably well defined currently, modulo the (largely aesthetic) consider= ations raised

On Thu, Nov 8, 2012 at 1:11 AM, Fat= ai Zhang <zhangfatai@huawei.com> wrote:

Hi Oscar, = Ed and all,

=C2= =A0

I totally = agree with Oscar.

=C2= =A0

I think we= should follow the regular procedures of PCE WG (IETF as well) to define th= e foundation work first including FWK, requirement, applicability before dropping into the solution stuff.

=C2=A0=

Guidance from WG chairs on = this stateful PCE work must be appreciated.

=C2=A0=

=C2=A0=

Best Regards<= /span>

=C2=A0=

Fatai<= /p>

=C2= =A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: pc= e-bounces@ietf.org [mailto:pce-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Oscar Gonz=C3=A1lez de D= ios
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2012=E5=B9=B411=E6=9C=888=E6=97=A5 8:17<= br> =E6=94=B6=E4=BB=B6=E4=BA=BA: Edward Crabbe
=E6=8A=84=E9=80=81: pce@ietf.org<= br> =E4=B8=BB=E9=A2=98: Re: [Pce] Questions about stateful PCE, relation to WG charter and = opinion about stateful PCE

=C2=A0

Hi Ed, answer= s inline,

=C2=A0

=C2=A0

IMO: they're the same = thing, the only difference is directionality and asynchrony.=C2=A0

[Oscar] Ag= ree.. Let=E2=80=99s see what our WG chairs say.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 My opinion in = the matter of the stateful PCE is that we should separate the functionality= is different functional elements, in the same way as it was done in the Fr= amework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In su= ch RFC, the roles of each functional element are clearly distinguished. Let= be the stateful PCE a Path Computation element using the traffic engineeri= ng database and the LSP database, and then, define another functional element (call it LSP controller, call = it manager) that is in care of the control issues.=

=C2=A0

This argument is orthogonal t= o the previous paragraph regarding the charter; =C2=A0let's separate th= e two discussions. ;)

[Oscar] Ag= ree, it=E2=80=99s a separate discussion.=

=C2=A0

w/r/t *element* separation= : I think that's a poor idea, sorry. =C2=A0It makes total sense to me that a given PCE would be able to negotiate and support statef= ul or stateless functionality.=C2=A0=

[Oscar] Wh= at I mean is to have a demarcation of the functional blocks. My problem is = that I may be too picky, but I like to call things by its name=E2=80=A6 and for me still Path Computation refers to the computation = function and not controlling. So path computation and control of a delegate= d LSP (or even initiation) are different functions, which are tightly conne= cted to solve the problems. I guess when you refer to negotiate =E2=80=9Cstateful=E2=80=9D functionality you are re= ferring to negotiate the delegation+whatever control functionalities and no= t only the fact of using (and synchronizing) the LSP Database. The confusio= n may come from the fact you see the =E2=80=9Cstateful PCE=E2=80=9D as the sum of a controller + a PCE + TEDB+LSPDB=E2=80=A6. =C2=A0I like tha= t entity, but, strictly speaking, it is more than a PCE =E2=80=A6=E2=80=A6 = But it is only a matter of naming, we all have agreed that the functionalit= y is needed, and that PCEP is a good protocol to support it.

I see this= =E2=80=9Ccontroller=E2=80=9D functional block as a generalization of the V= NTM functional block defined in RFC 5623 for the specific case of controlli= ng/managing an overlay network.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Said that, I m= ust say that I like the new functionalities proposed , and I think they sol= ve problems (and people also did like them, as the stateful draft was suppo= rted by the WG people). What I do not like at all is how it is being handled. There has been a solution quickly = adopted without taking any care in the architectural/functional implication= s. In my opinion we should handle them now.=

=C2=A0

Define quickly man? =C2=A0The= original draft went through multiple rounds of review both on list and in = multiple (technically two but really three) IETF meetings before acceptance.

=C2=A0It has received, as = you said, broad support and review by many people on the list, including yo= u. ;) It is at a relatively low rev count and is still a work in progress. =C2=A0 =C2=A0

[Oscar] An= d I do support it and like it! I meant quickly because it went through dire= ctly as a solution. Other pieces of work had to deal first with the framework/requirements and then jump in the solution, there are p= lenty of examples around, you can see the time of the first draft of the fr= amework/requirements and the time of the adoption of the first WG solution= =E2=80=A6. (Interlayer, GMPLS, H-PCE)=E2=80=A6 This stateful PCE approach has a lot of implications, this is why I think we sh= ould take it with care and make it work together, with a clear architecture= and make a good framework to have solid foundations.

=C2=A0

=C2=A0best,

=C2=A0 -ed

=C2=A0=

Best Regards,=

=C2=A0=

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C3=93scar

=C2=A0

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3=B3ni= co en el enlace situado m=C3=A1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
= http://www.tid.es/ES/PAGINAS/disclaimer.aspx

--f46d043be1e010534504cdf731af-- From cyril.margaria@nsn.com Thu Nov 8 06:57:19 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC221F890A for ; Thu, 8 Nov 2012 06:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 grFH0GRycdLq for ; Thu, 8 Nov 2012 06:57:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C627E21F8B16 for ; Thu, 8 Nov 2012 06:57:14 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id qA8Ev1AN030424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Nov 2012 15:57:01 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id qA8Euwfh018716; Thu, 8 Nov 2012 15:57:01 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Nov 2012 15:56:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDBDC1.4CA06089" Date: Thu, 8 Nov 2012 15:52:18 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?utf-8?B?W1BjZV3nrZTlpI06ICBRdWVzdGlvbnMgYWJvdXQgc3RhdGVm?= =?utf-8?B?dWwgUENFLCByZWxhdGlvbiB0byBXRyBjaGFydGVyIGE=?= =?utf-8?B?bmQgb3BpbmlvbiBhYm91dCBzdGF0ZWZ1bCBQQ0U=?= Thread-Index: Ac29hskaKG6G5I9aQyiqMzMLTWelmQANusTw References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet><7CFF94B047D8864CB6268315034E35DE08A71B14@EX10-MB2-MAD.hi.inet>

From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Edward Crabbe" , "Fatai Zhang" X-OriginalArrivalTime: 08 Nov 2012 14:56:57.0412 (UTC) FILETIME=[4C8AE040:01CDBDC1] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 39740 X-purgate-ID: 151667::1352386622-00003C61-E291F33D/0-0/0-0 Cc: pce@ietf.org Subject: Re: [Pce] =?utf-8?b?562U5aSNOiAgUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBD?= =?utf-8?q?E=2C_relation_to_WG_charter_and_opinion_about_stateful_P?= =?utf-8?q?CE?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:57:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDBDC1.4CA06089 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIA0KDQogDQoNCkkgYWdyZWUgd2l0aCBvc2NhciBhbmQgRmF0YWkgVGhlIGRlbGVnYXRpb24v dXBkYXRlIGFuZCB0aGUgaW5pdGlhdGlvbiBhcmUgcmVsYXRlZC4NCg0KIA0KDQpSZWdhcmRpbmcg YSkgSSByZWNhbGwgdGhlIGluIHRoZSBXRyBtZWV0aW5nLCAgb25lIGNvbW1lbnQgZnJvbSB0aGUg Y2hhaXJzICB3YXMgdGhlIHNlcnZpY2UgcmVxdWVzdCBpbiBSRkM0NjU1IGlzIG5vdCBwYXJ0IG9m IHRoZSBjb21wdXRhdGlvbiBwYXJ0Lg0KDQpJbiB0aGlzIHJlZ2FyZCBpdCB3b3VsZCBiZSBnb29k IHRvIGFkZHJlc3MgdGhvc2UgYXJjaGl0ZWN0dXJhbCBwb2ludHMsIGJ1dCBpZiB3ZSBoYXZlIHNv bWUgZG91YnRzIHdlIGNvdWxkIGFzayBuZXR3b3JrIG1hbmFnZW1lbnQgcmVsYXRlZCBXR3MgOy0p DQoNCiANCg0KUmVnYXJkaW5nIGIpIHRoaXMgZG9lcyBub3QgcHJldmVudCB0byBjbGFyaWZ5IHdo ZXJlIGRvZXMgaXQgZml0IGluIHRoZSBQQ0UgYXJjaGl0ZWN0dXJlLg0KDQogDQoNCiANCg0KIA0K DQpCZXN0IHJlZ2FyZHMgLyBNaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuDQoNCkN5cmlsIE1hcmdh cmlhDQoNCiANCg0KRnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBFZHdhcmQgQ3JhYmJlDQpTZW50OiBUaHVyc2Rh eSwgTm92ZW1iZXIgMDgsIDIwMTIgODo1NyBBTQ0KVG86IEZhdGFpIFpoYW5nDQpDYzogcGNlQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW1BjZV3nrZTlpI06IFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1 bCBQQ0UsIHJlbGF0aW9uIHRvIFdHIGNoYXJ0ZXIgYW5kIG9waW5pb24gYWJvdXQgc3RhdGVmdWwg UENFDQoNCiANCg0KQUZBSUs6DQoNCiANCg0KKGEpOiB3ZSBhcmUgZ2V0dGluZyBndWlkYW5jZSBm cm9tIHRoZSBjaGFpcnMgb24gYW4gb25nb2luZyBiYXNpcyBhbmQNCg0KKGIpOiB0aGUgc29sdXRp b24gYW5kIGZyYW1ld29yayBhcmUgY291cGxlZCBhbmQgYXJlIHJlYXNvbmFibHkgd2VsbCBkZWZp bmVkIGN1cnJlbnRseSwgbW9kdWxvIHRoZSAobGFyZ2VseSBhZXN0aGV0aWMpIGNvbnNpZGVyYXRp b25zIHJhaXNlZA0KDQogDQoNCk9uIFRodSwgTm92IDgsIDIwMTIgYXQgMToxMSBBTSwgRmF0YWkg WmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCkhpIE9zY2FyLCBFZCBhbmQg YWxsLA0KDQogDQoNCkkgdG90YWxseSBhZ3JlZSB3aXRoIE9zY2FyLiANCg0KIA0KDQpJIHRoaW5r IHdlIHNob3VsZCBmb2xsb3cgdGhlIHJlZ3VsYXIgcHJvY2VkdXJlcyBvZiBQQ0UgV0cgKElFVEYg YXMgd2VsbCkgdG8gZGVmaW5lIHRoZSBmb3VuZGF0aW9uIHdvcmsgZmlyc3QgaW5jbHVkaW5nIEZX SywgcmVxdWlyZW1lbnQsIGFwcGxpY2FiaWxpdHkgYmVmb3JlIGRyb3BwaW5nIGludG8gdGhlIHNv bHV0aW9uIHN0dWZmLiANCg0KIA0KDQpHdWlkYW5jZSBmcm9tIFdHIGNoYWlycyBvbiB0aGlzIHN0 YXRlZnVsIFBDRSB3b3JrIG11c3QgYmUgYXBwcmVjaWF0ZWQuDQoNCiANCg0KIA0KDQpCZXN0IFJl Z2FyZHMNCg0KIA0KDQpGYXRhaQ0KDQogDQoNCuWPkeS7tuS6ujogcGNlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE9zY2FyIEdvbnrDoWxleiBk ZSBEaW9zDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQxMeaciDjml6UgODoxNw0K5pS25Lu25Lq6OiBF ZHdhcmQgQ3JhYmJlDQrmioTpgIE6IHBjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW1BjZV0gUXVl c3Rpb25zIGFib3V0IHN0YXRlZnVsIFBDRSwgcmVsYXRpb24gdG8gV0cgY2hhcnRlciBhbmQgb3Bp bmlvbiBhYm91dCBzdGF0ZWZ1bCBQQ0UNCg0KIA0KDQpIaSBFZCwgYW5zd2VycyBpbmxpbmUsDQoN CiANCg0KIA0KDQpJTU86IHRoZXkncmUgdGhlIHNhbWUgdGhpbmcsIHRoZSBvbmx5IGRpZmZlcmVu Y2UgaXMgZGlyZWN0aW9uYWxpdHkgYW5kIGFzeW5jaHJvbnkuIA0KDQpbT3NjYXJdIEFncmVlLi4g TGV04oCZcyBzZWUgd2hhdCBvdXIgV0cgY2hhaXJzIHNheS4NCg0KIA0KDQoJICAgICAgICAgICAg ICAgIE15IG9waW5pb24gaW4gdGhlIG1hdHRlciBvZiB0aGUgc3RhdGVmdWwgUENFIGlzIHRoYXQg d2Ugc2hvdWxkIHNlcGFyYXRlIHRoZSBmdW5jdGlvbmFsaXR5IGlzIGRpZmZlcmVudCBmdW5jdGlv bmFsIGVsZW1lbnRzLCBpbiB0aGUgc2FtZSB3YXkgYXMgaXQgd2FzIGRvbmUgaW4gdGhlIEZyYW1l d29yayBmb3IgUENFLUJhc2VkIEludGVyLUxheWVyIE1QTFMgYW5kIEdNUExTIFRyYWZmaWMgRW5n aW5lZXJpbmcgKFJGQyA1NjIzKSBiZXR3ZWVuIGEgVk5UTSBhbmQgdGhlIFBDRS4gSW4gc3VjaCBS RkMsIHRoZSByb2xlcyBvZiBlYWNoIGZ1bmN0aW9uYWwgZWxlbWVudCBhcmUgY2xlYXJseSBkaXN0 aW5ndWlzaGVkLiBMZXQgYmUgdGhlIHN0YXRlZnVsIFBDRSBhIFBhdGggQ29tcHV0YXRpb24gZWxl bWVudCB1c2luZyB0aGUgdHJhZmZpYyBlbmdpbmVlcmluZyBkYXRhYmFzZSBhbmQgdGhlIExTUCBk YXRhYmFzZSwgYW5kIHRoZW4sIGRlZmluZSBhbm90aGVyIGZ1bmN0aW9uYWwgZWxlbWVudCAoY2Fs bCBpdCBMU1AgY29udHJvbGxlciwgY2FsbCBpdCBtYW5hZ2VyKSB0aGF0IGlzIGluIGNhcmUgb2Yg dGhlIGNvbnRyb2wgaXNzdWVzLg0KDQogDQoNClRoaXMgYXJndW1lbnQgaXMgb3J0aG9nb25hbCB0 byB0aGUgcHJldmlvdXMgcGFyYWdyYXBoIHJlZ2FyZGluZyB0aGUgY2hhcnRlcjsgIGxldCdzIHNl cGFyYXRlIHRoZSB0d28gZGlzY3Vzc2lvbnMuIDspDQoNCltPc2Nhcl0gQWdyZWUsIGl04oCZcyBh IHNlcGFyYXRlIGRpc2N1c3Npb24uDQoNCiANCg0Kdy9yL3QgKmVsZW1lbnQqIHNlcGFyYXRpb246 IEkgdGhpbmsgdGhhdCdzIGEgcG9vciBpZGVhLCBzb3JyeS4gIEl0IG1ha2VzIHRvdGFsIHNlbnNl IHRvIG1lIHRoYXQgYSBnaXZlbiBQQ0Ugd291bGQgYmUgYWJsZSB0byBuZWdvdGlhdGUgYW5kIHN1 cHBvcnQgc3RhdGVmdWwgb3Igc3RhdGVsZXNzIGZ1bmN0aW9uYWxpdHkuIA0KDQpbT3NjYXJdIFdo YXQgSSBtZWFuIGlzIHRvIGhhdmUgYSBkZW1hcmNhdGlvbiBvZiB0aGUgZnVuY3Rpb25hbCBibG9j a3MuIE15IHByb2JsZW0gaXMgdGhhdCBJIG1heSBiZSB0b28gcGlja3ksIGJ1dCBJIGxpa2UgdG8g Y2FsbCB0aGluZ3MgYnkgaXRzIG5hbWXigKYgYW5kIGZvciBtZSBzdGlsbCBQYXRoIENvbXB1dGF0 aW9uIHJlZmVycyB0byB0aGUgY29tcHV0YXRpb24gZnVuY3Rpb24gYW5kIG5vdCBjb250cm9sbGlu Zy4gU28gcGF0aCBjb21wdXRhdGlvbiBhbmQgY29udHJvbCBvZiBhIGRlbGVnYXRlZCBMU1AgKG9y IGV2ZW4gaW5pdGlhdGlvbikgYXJlIGRpZmZlcmVudCBmdW5jdGlvbnMsIHdoaWNoIGFyZSB0aWdo dGx5IGNvbm5lY3RlZCB0byBzb2x2ZSB0aGUgcHJvYmxlbXMuIEkgZ3Vlc3Mgd2hlbiB5b3UgcmVm ZXIgdG8gbmVnb3RpYXRlIOKAnHN0YXRlZnVs4oCdIGZ1bmN0aW9uYWxpdHkgeW91IGFyZSByZWZl cnJpbmcgdG8gbmVnb3RpYXRlIHRoZSBkZWxlZ2F0aW9uK3doYXRldmVyIGNvbnRyb2wgZnVuY3Rp b25hbGl0aWVzIGFuZCBub3Qgb25seSB0aGUgZmFjdCBvZiB1c2luZyAoYW5kIHN5bmNocm9uaXpp bmcpIHRoZSBMU1AgRGF0YWJhc2UuIFRoZSBjb25mdXNpb24gbWF5IGNvbWUgZnJvbSB0aGUgZmFj dCB5b3Ugc2VlIHRoZSDigJxzdGF0ZWZ1bCBQQ0XigJ0gYXMgdGhlIHN1bSBvZiBhIGNvbnRyb2xs ZXIgKyBhIFBDRSArIFRFREIrTFNQRELigKYuICBJIGxpa2UgdGhhdCBlbnRpdHksIGJ1dCwgc3Ry aWN0bHkgc3BlYWtpbmcsIGl0IGlzIG1vcmUgdGhhbiBhIFBDRSDigKbigKYgQnV0IGl0IGlzIG9u bHkgYSBtYXR0ZXIgb2YgbmFtaW5nLCB3ZSBhbGwgaGF2ZSBhZ3JlZWQgdGhhdCB0aGUgZnVuY3Rp b25hbGl0eSBpcyBuZWVkZWQsIGFuZCB0aGF0IFBDRVAgaXMgYSBnb29kIHByb3RvY29sIHRvIHN1 cHBvcnQgaXQuDQoNCkkgc2VlIHRoaXMg4oCcY29udHJvbGxlcuKAnSBmdW5jdGlvbmFsIGJsb2Nr IGFzIGEgZ2VuZXJhbGl6YXRpb24gb2YgdGhlIFZOVE0gZnVuY3Rpb25hbCBibG9jayBkZWZpbmVk IGluIFJGQyA1NjIzIGZvciB0aGUgc3BlY2lmaWMgY2FzZSBvZiBjb250cm9sbGluZy9tYW5hZ2lu ZyBhbiBvdmVybGF5IG5ldHdvcmsuDQoNCiANCg0KCSAgICAgICAgICAgICAgICBTYWlkIHRoYXQs IEkgbXVzdCBzYXkgdGhhdCBJIGxpa2UgdGhlIG5ldyBmdW5jdGlvbmFsaXRpZXMgcHJvcG9zZWQg LCBhbmQgSSB0aGluayB0aGV5IHNvbHZlIHByb2JsZW1zIChhbmQgcGVvcGxlIGFsc28gZGlkIGxp a2UgdGhlbSwgYXMgdGhlIHN0YXRlZnVsIGRyYWZ0IHdhcyBzdXBwb3J0ZWQgYnkgdGhlIFdHIHBl b3BsZSkuIFdoYXQgSSBkbyBub3QgbGlrZSBhdCBhbGwgaXMgaG93IGl0IGlzIGJlaW5nIGhhbmRs ZWQuIFRoZXJlIGhhcyBiZWVuIGEgc29sdXRpb24gcXVpY2tseSBhZG9wdGVkIHdpdGhvdXQgdGFr aW5nIGFueSBjYXJlIGluIHRoZSBhcmNoaXRlY3R1cmFsL2Z1bmN0aW9uYWwgaW1wbGljYXRpb25z LiBJbiBteSBvcGluaW9uIHdlIHNob3VsZCBoYW5kbGUgdGhlbSBub3cuDQoNCiANCg0KRGVmaW5l IHF1aWNrbHkgbWFuPyAgVGhlIG9yaWdpbmFsIGRyYWZ0IHdlbnQgdGhyb3VnaCBtdWx0aXBsZSBy b3VuZHMgb2YgcmV2aWV3IGJvdGggb24gbGlzdCBhbmQgaW4gbXVsdGlwbGUgKHRlY2huaWNhbGx5 IHR3byBidXQgcmVhbGx5IHRocmVlKSBJRVRGIG1lZXRpbmdzIGJlZm9yZSBhY2NlcHRhbmNlLiAN Cg0KIEl0IGhhcyByZWNlaXZlZCwgYXMgeW91IHNhaWQsIGJyb2FkIHN1cHBvcnQgYW5kIHJldmll dyBieSBtYW55IHBlb3BsZSBvbiB0aGUgbGlzdCwgaW5jbHVkaW5nIHlvdS4gOykgSXQgaXMgYXQg YSByZWxhdGl2ZWx5IGxvdyByZXYgY291bnQgYW5kIGlzIHN0aWxsIGEgd29yayBpbiBwcm9ncmVz cy4gICAgDQoNCltPc2Nhcl0gQW5kIEkgZG8gc3VwcG9ydCBpdCBhbmQgbGlrZSBpdCEgSSBtZWFu dCBxdWlja2x5IGJlY2F1c2UgaXQgd2VudCB0aHJvdWdoIGRpcmVjdGx5IGFzIGEgc29sdXRpb24u IE90aGVyIHBpZWNlcyBvZiB3b3JrIGhhZCB0byBkZWFsIGZpcnN0IHdpdGggdGhlIGZyYW1ld29y ay9yZXF1aXJlbWVudHMgYW5kIHRoZW4ganVtcCBpbiB0aGUgc29sdXRpb24sIHRoZXJlIGFyZSBw bGVudHkgb2YgZXhhbXBsZXMgYXJvdW5kLCB5b3UgY2FuIHNlZSB0aGUgdGltZSBvZiB0aGUgZmly c3QgZHJhZnQgb2YgdGhlIGZyYW1ld29yay9yZXF1aXJlbWVudHMgYW5kIHRoZSB0aW1lIG9mIHRo ZSBhZG9wdGlvbiBvZiB0aGUgZmlyc3QgV0cgc29sdXRpb27igKYuIChJbnRlcmxheWVyLCBHTVBM UywgSC1QQ0Up4oCmIFRoaXMgc3RhdGVmdWwgUENFIGFwcHJvYWNoIGhhcyBhIGxvdCBvZiBpbXBs aWNhdGlvbnMsIHRoaXMgaXMgd2h5IEkgdGhpbmsgd2Ugc2hvdWxkIHRha2UgaXQgd2l0aCBjYXJl IGFuZCBtYWtlIGl0IHdvcmsgdG9nZXRoZXIsIHdpdGggYSBjbGVhciBhcmNoaXRlY3R1cmUgYW5k IG1ha2UgYSBnb29kIGZyYW1ld29yayB0byBoYXZlIHNvbGlkIGZvdW5kYXRpb25zLg0KDQogDQoN CiBiZXN0LA0KDQogIC1lZA0KDQogDQoNCkJlc3QgUmVnYXJkcywNCg0KIA0KDQogICAgICAgICAg ICAgICAgw5NzY2FyDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K DQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlv LiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOz biBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8u DQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNw eA0KDQogDQoNCg== ------_=_NextPart_001_01CDBDC1.4CA06089 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiAz IDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1pbmdMaVUi Ow0KCXBhbm9zZS0xOjIgMiAzIDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIFVJIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBVSSBHb3Ro aWMiOw0KCXBhbm9zZS0xOjIgMTEgNiAwIDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk65a6L5L2TO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6I0MwMDAwMDsN Cgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtc2hhZG93Om5vbmU7DQoJdGV4dC1kZWNvcmF0 aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzAwMDAwJz5IaSwgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDAwMDAnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzAwMDAwJz5J IGFncmVlIHdpdGggb3NjYXIgYW5kIEZhdGFpIFRoZSBkZWxlZ2F0aW9uL3VwZGF0ZSBhbmQgdGhl IGluaXRpYXRpb24gYXJlIHJlbGF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDAwMDAnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzAwMDAwJz5SZWdhcmRpbmcgYSkg SSByZWNhbGwgdGhlIGluIHRoZSBXRyBtZWV0aW5nLCDCoG9uZSBjb21tZW50IGZyb20gdGhlIGNo YWlycyDCoHdhcyB0aGUgc2VydmljZSByZXF1ZXN0IGluIFJGQzQ2NTUgaXMgbm90IHBhcnQgb2Yg dGhlIGNvbXB1dGF0aW9uIHBhcnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiNDMDAwMDAnPkluIHRoaXMgcmVnYXJkIGl0IHdvdWxkIGJlIGdv b2QgdG8gYWRkcmVzcyB0aG9zZSBhcmNoaXRlY3R1cmFsIHBvaW50cywgYnV0IGlmIHdlIGhhdmUg c29tZSBkb3VidHMgd2UgY291bGQgYXNrIG5ldHdvcmsgbWFuYWdlbWVudCByZWxhdGVkIFdHcyA7 LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 I0MwMDAwMCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiNDMDAwMDAnPlJlZ2FyZGluZyBiKSB0aGlzIGRvZXMgbm90IHByZXZlbnQg dG8gY2xhcmlmeSB3aGVyZSBkb2VzIGl0IGZpdCBpbiB0aGUgUENFIGFyY2hpdGVjdHVyZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwMDAw MCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiNDMDAwMDAnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDAwMDAnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQt YXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwMDAwMCc+QmVzdCByZWdhcmRz IC8gTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYXV0b3NwYWNlOm5vbmUnPjxzcGFuIGxhbmc9REUgc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwMDAwMCc+Q3lyaWwgTWFyZ2FyaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzAwMDAwJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz4gcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10g PGI+T24gQmVoYWxmIE9mIDwvYj5leHQgRWR3YXJkIENyYWJiZTxicj48Yj5TZW50OjwvYj4gVGh1 cnNkYXksIE5vdmVtYmVyIDA4LCAyMDEyIDg6NTcgQU08YnI+PGI+VG86PC9iPiBGYXRhaSBaaGFu Zzxicj48Yj5DYzo8L2I+IHBjZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtQY2Vd PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBVSSBH b3RoaWMiLCJzYW5zLXNlcmlmIic+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+OiBRdWVzdGlvbnMgYWJv dXQgc3RhdGVmdWwgUENFLCByZWxhdGlvbiB0byBXRyBjaGFydGVyIGFuZCBvcGluaW9uIGFib3V0 IHN0YXRlZnVsIFBDRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPkFGQUlLOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz4oYSk6IHdlIGFyZSBnZXR0aW5nIGd1aWRhbmNlIGZyb20gdGhlIGNoYWly cyBvbiBhbiBvbmdvaW5nIGJhc2lzIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+KGIpOiB0aGUgc29sdXRpb24gYW5kIGZyYW1ld29y ayBhcmUgY291cGxlZCBhbmQgYXJlIHJlYXNvbmFibHkgd2VsbCBkZWZpbmVkIGN1cnJlbnRseSwg bW9kdWxvIHRoZSAobGFyZ2VseSBhZXN0aGV0aWMpIGNvbnNpZGVyYXRpb25zIHJhaXNlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPk9uIFRodSwgTm92IDgsIDIwMTIgYXQgMToxMSBB TSwgRmF0YWkgWmhhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb20i IHRhcmdldD0iX2JsYW5rIj56aGFuZ2ZhdGFpQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+SGkgT3NjYXIsIEVkIGFuZCBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SSB0b3RhbGx5IGFncmVlIHdpdGggT3NjYXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkg dGhpbmsgd2Ugc2hvdWxkIGZvbGxvdyB0aGUgcmVndWxhciBwcm9jZWR1cmVzIG9mIFBDRSBXRyAo SUVURiBhcyB3ZWxsKSB0byBkZWZpbmUgdGhlIGZvdW5kYXRpb24gd29yayBmaXJzdCBpbmNsdWRp bmcgRldLLCByZXF1aXJlbWVudCwgYXBwbGljYWJpbGl0eSBiZWZvcmUgZHJvcHBpbmcgaW50byB0 aGUgc29sdXRpb24gc3R1ZmYuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1hbGlnbjpqdXN0aWZ5Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVz dGlmeSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5HdWlkYW5jZSBmcm9tIFdHIGNoYWlycyBvbiB0 aGlzIHN0YXRlZnVsIFBDRSB3b3JrIG11c3QgYmUgYXBwcmVjaWF0ZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpqdXN0aWZ5Jz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO3RleHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnkn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QmVzdCBSZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpqdXN0aWZ5Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYWxpZ246anVzdGlmeSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5GYXRhaTwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVUnPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TJz46PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMnPiA8 YSBocmVmPSJtYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wY2Ut Ym91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cGNlLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wY2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDwvc3Bh bj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJNUyBHb3RoaWMiJz7ku6Pooag8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TJz4gPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMnPk9zY2FyIEdvbnrDoWxl eiBkZSBEaW9zPGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVUnPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TJz46PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMnPiAyMDEy PC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Ik1TIEdvdGhpYyInPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTrlrovkvZMnPjExPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaciDwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMnPjg8L3NwYW4+PHNwYW4gbGFu Zz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgR290aGljIic+ 5pelPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9 kyc+IDg6MTc8YnI+PC9zcGFuPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyInPuaUtuS7tuS6ujwvc3Bhbj48L2I+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TJz46PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMnPiBFZHdh cmQgQ3JhYmJlPGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyc+Ojwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TJz4gPGEgaHJl Zj0ibWFpbHRvOnBjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBjZUBpZXRmLm9yZzwvYT48 YnI+PC9zcGFuPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6Ik1TIEdvdGhpYyInPuS4uzwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz1aSC1DTiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVJz7popg8L3NwYW4+PC9i PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyc+Ojwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T Jz4gUmU6IFtQY2VdIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0UsIHJlbGF0aW9uIHRvIFdH IGNoYXJ0ZXIgYW5kIG9waW5pb24gYWJvdXQgc3RhdGVmdWwgUENFPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5IaSBFZCwgYW5zd2VycyBpbmxpbmUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxk aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn PklNTzogdGhleSdyZSB0aGUgc2FtZSB0aGluZywgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBkaXJl Y3Rpb25hbGl0eSBhbmQgYXN5bmNocm9ueS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bT3NjYXJdIEFncmVlLi4g TGV04oCZcyBzZWUgd2hhdCBvdXIgV0cgY2hhaXJzIHNheS48L3NwYW4+PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE15IG9waW5pb24gaW4gdGhlIG1hdHRlciBvZiB0aGUgc3RhdGVmdWwgUENFIGlz IHRoYXQgd2Ugc2hvdWxkIHNlcGFyYXRlIHRoZSBmdW5jdGlvbmFsaXR5IGlzIGRpZmZlcmVudCBm dW5jdGlvbmFsIGVsZW1lbnRzLCBpbiB0aGUgc2FtZSB3YXkgYXMgaXQgd2FzIGRvbmUgaW4gdGhl IEZyYW1ld29yayBmb3IgUENFLUJhc2VkIEludGVyLUxheWVyIE1QTFMgYW5kIEdNUExTIFRyYWZm aWMgRW5naW5lZXJpbmcgKFJGQyA1NjIzKSBiZXR3ZWVuIGEgVk5UTSBhbmQgdGhlIFBDRS4gSW4g c3VjaCBSRkMsIHRoZSByb2xlcyBvZiBlYWNoIGZ1bmN0aW9uYWwgZWxlbWVudCBhcmUgY2xlYXJs eSBkaXN0aW5ndWlzaGVkLiBMZXQgYmUgdGhlIHN0YXRlZnVsIFBDRSBhIFBhdGggQ29tcHV0YXRp b24gZWxlbWVudCB1c2luZyB0aGUgdHJhZmZpYyBlbmdpbmVlcmluZyBkYXRhYmFzZSBhbmQgdGhl IExTUCBkYXRhYmFzZSwgYW5kIHRoZW4sIGRlZmluZSBhbm90aGVyIGZ1bmN0aW9uYWwgZWxlbWVu dCAoY2FsbCBpdCBMU1AgY29udHJvbGxlciwgY2FsbCBpdCBtYW5hZ2VyKSB0aGF0IGlzIGluIGNh cmUgb2YgdGhlIGNvbnRyb2wgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90 ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9 RVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPlRoaXMgYXJndW1lbnQgaXMgb3J0aG9nb25hbCB0byB0aGUgcHJldmlvdXMgcGFyYWdyYXBo IHJlZ2FyZGluZyB0aGUgY2hhcnRlcjsgJm5ic3A7bGV0J3Mgc2VwYXJhdGUgdGhlIHR3byBkaXNj dXNzaW9ucy4gOyk8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5bT3NjYXJdIEFncmVlLCBpdOKAmXMgYSBzZXBhcmF0ZSBkaXNj dXNzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz53L3IvdCAqZWxlbWVudCogc2VwYXJhdGlvbjogSSB0 aGluayB0aGF0J3MgYSBwb29yIGlkZWEsIHNvcnJ5LiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1F UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+SXQgbWFrZXMgdG90YWwgc2Vuc2UgdG8gbWUgdGhhdCBhIGdpdmVuIFBDRSB3b3VsZCBiZSBh YmxlIHRvIG5lZ290aWF0ZSBhbmQgc3VwcG9ydCBzdGF0ZWZ1bCBvciBzdGF0ZWxlc3MgZnVuY3Rp b25hbGl0eS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bT3NjYXJdIFdoYXQgSSBtZWFuIGlzIHRvIGhhdmUgYSBk ZW1hcmNhdGlvbiBvZiB0aGUgZnVuY3Rpb25hbCBibG9ja3MuIE15IHByb2JsZW0gaXMgdGhhdCBJ IG1heSBiZSB0b28gcGlja3ksIGJ1dCBJIGxpa2UgdG8gY2FsbCB0aGluZ3MgYnkgaXRzIG5hbWXi gKYgYW5kIGZvciBtZSBzdGlsbCBQYXRoIENvbXB1dGF0aW9uIHJlZmVycyB0byB0aGUgY29tcHV0 YXRpb24gZnVuY3Rpb24gYW5kIG5vdCBjb250cm9sbGluZy4gU28gcGF0aCBjb21wdXRhdGlvbiBh bmQgY29udHJvbCBvZiBhIGRlbGVnYXRlZCBMU1AgKG9yIGV2ZW4gaW5pdGlhdGlvbikgYXJlIGRp ZmZlcmVudCBmdW5jdGlvbnMsIHdoaWNoIGFyZSB0aWdodGx5IGNvbm5lY3RlZCB0byBzb2x2ZSB0 aGUgcHJvYmxlbXMuIEkgZ3Vlc3Mgd2hlbiB5b3UgcmVmZXIgdG8gbmVnb3RpYXRlIOKAnHN0YXRl ZnVs4oCdIGZ1bmN0aW9uYWxpdHkgeW91IGFyZSByZWZlcnJpbmcgdG8gbmVnb3RpYXRlIHRoZSBk ZWxlZ2F0aW9uK3doYXRldmVyIGNvbnRyb2wgZnVuY3Rpb25hbGl0aWVzIGFuZCBub3Qgb25seSB0 aGUgZmFjdCBvZiB1c2luZyAoYW5kIHN5bmNocm9uaXppbmcpIHRoZSBMU1AgRGF0YWJhc2UuIFRo ZSBjb25mdXNpb24gbWF5IGNvbWUgZnJvbSB0aGUgZmFjdCB5b3Ugc2VlIHRoZSDigJxzdGF0ZWZ1 bCBQQ0XigJ0gYXMgdGhlIHN1bSBvZiBhIGNvbnRyb2xsZXIgKyBhIFBDRSArIFRFREIrTFNQRELi gKYuICZuYnNwO0kgbGlrZSB0aGF0IGVudGl0eSwgYnV0LCBzdHJpY3RseSBzcGVha2luZywgaXQg aXMgbW9yZSB0aGFuIGEgUENFIOKApuKApiBCdXQgaXQgaXMgb25seSBhIG1hdHRlciBvZiBuYW1p bmcsIHdlIGFsbCBoYXZlIGFncmVlZCB0aGF0IHRoZSBmdW5jdGlvbmFsaXR5IGlzIG5lZWRlZCwg YW5kIHRoYXQgUENFUCBpcyBhIGdvb2QgcHJvdG9jb2wgdG8gc3VwcG9ydCBpdC48L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J IHNlZSB0aGlzIOKAnGNvbnRyb2xsZXLigJ0gZnVuY3Rpb25hbCBibG9jayBhcyBhIGdlbmVyYWxp emF0aW9uIG9mIHRoZSBWTlRNIGZ1bmN0aW9uYWwgYmxvY2sgZGVmaW5lZCBpbiBSRkMgNTYyMyBm b3IgdGhlIHNwZWNpZmljIGNhc2Ugb2YgY29udHJvbGxpbmcvbWFuYWdpbmcgYW4gb3ZlcmxheSBu ZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FpZCB0aGF0LCBJIG11c3Qg c2F5IHRoYXQgSSBsaWtlIHRoZSBuZXcgZnVuY3Rpb25hbGl0aWVzIHByb3Bvc2VkICwgYW5kIEkg dGhpbmsgdGhleSBzb2x2ZSBwcm9ibGVtcyAoYW5kIHBlb3BsZSBhbHNvIGRpZCBsaWtlIHRoZW0s IGFzIHRoZSBzdGF0ZWZ1bCBkcmFmdCB3YXMgc3VwcG9ydGVkIGJ5IHRoZSBXRyBwZW9wbGUpLiBX aGF0IEkgZG8gbm90IGxpa2UgYXQgYWxsIGlzIGhvdyBpdCBpcyBiZWluZyBoYW5kbGVkLiBUaGVy ZSBoYXMgYmVlbiBhIHNvbHV0aW9uIHF1aWNrbHkgYWRvcHRlZCB3aXRob3V0IHRha2luZyBhbnkg Y2FyZSBpbiB0aGUgYXJjaGl0ZWN0dXJhbC9mdW5jdGlvbmFsIGltcGxpY2F0aW9ucy4gSW4gbXkg b3BpbmlvbiB3ZSBzaG91bGQgaGFuZGxlIHRoZW0gbm93LjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIGxhbmc9RVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPkRlZmluZSBxdWlja2x5IG1hbj8gJm5ic3A7VGhlIG9yaWdpbmFsIGRyYWZ0 IHdlbnQgdGhyb3VnaCBtdWx0aXBsZSByb3VuZHMgb2YgcmV2aWV3IGJvdGggb24gbGlzdCBhbmQg aW4gbXVsdGlwbGUgKHRlY2huaWNhbGx5IHR3byBidXQgcmVhbGx5IHRocmVlKSBJRVRGIG1lZXRp bmdzIGJlZm9yZSBhY2NlcHRhbmNlLiA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPiZuYnNwO0l0IGhhcyByZWNlaXZlZCwgYXMgeW91IHNhaWQsIGJyb2Fk IHN1cHBvcnQgYW5kIHJldmlldyBieSBtYW55IHBlb3BsZSBvbiB0aGUgbGlzdCwgaW5jbHVkaW5n IHlvdS4gOykgSXQgaXMgYXQgYSByZWxhdGl2ZWx5IGxvdyByZXYgY291bnQgYW5kIGlzIHN0aWxs IGEgd29yayBpbiBwcm9ncmVzcy4gJm5ic3A7ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltPc2Nhcl0gQW5kIEkg ZG8gc3VwcG9ydCBpdCBhbmQgbGlrZSBpdCEgSSBtZWFudCBxdWlja2x5IGJlY2F1c2UgaXQgd2Vu dCB0aHJvdWdoIGRpcmVjdGx5IGFzIGEgc29sdXRpb24uIE90aGVyIHBpZWNlcyBvZiB3b3JrIGhh ZCB0byBkZWFsIGZpcnN0IHdpdGggdGhlIGZyYW1ld29yay9yZXF1aXJlbWVudHMgYW5kIHRoZW4g anVtcCBpbiB0aGUgc29sdXRpb24sIHRoZXJlIGFyZSBwbGVudHkgb2YgZXhhbXBsZXMgYXJvdW5k LCB5b3UgY2FuIHNlZSB0aGUgdGltZSBvZiB0aGUgZmlyc3QgZHJhZnQgb2YgdGhlIGZyYW1ld29y ay9yZXF1aXJlbWVudHMgYW5kIHRoZSB0aW1lIG9mIHRoZSBhZG9wdGlvbiBvZiB0aGUgZmlyc3Qg V0cgc29sdXRpb27igKYuIChJbnRlcmxheWVyLCBHTVBMUywgSC1QQ0Up4oCmIFRoaXMgc3RhdGVm dWwgUENFIGFwcHJvYWNoIGhhcyBhIGxvdCBvZiBpbXBsaWNhdGlvbnMsIHRoaXMgaXMgd2h5IEkg dGhpbmsgd2Ugc2hvdWxkIHRha2UgaXQgd2l0aCBjYXJlIGFuZCBtYWtlIGl0IHdvcmsgdG9nZXRo ZXIsIHdpdGggYSBjbGVhciBhcmNoaXRlY3R1cmUgYW5kIG1ha2UgYSBnb29kIGZyYW1ld29yayB0 byBoYXZlIHNvbGlkIGZvdW5kYXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9RVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPmJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7IC1lZDwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9 RVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDDk3NjYXI8 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+PHNwYW4gbGFuZz1FUz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdiBj bGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw YW4gbGFuZz1FUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+PGhyIHNpemU9MyB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVTIHN0eWxlPSdmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Z3JheSc+PGJyPkVz dGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1 ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRl IGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby48YnI+ VGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBX ZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBz ZXQgb3V0IGF0Ojxicj48YSBocmVmPSJodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2Ns YWltZXIuYXNweCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMv ZGlzY2xhaW1lci5hc3B4PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CDBDC1.4CA06089-- From julien.meuric@orange.com Thu Nov 8 13:40:52 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682ED21F889E for ; Thu, 8 Nov 2012 13:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 J55uNXP-KK5X for ; Thu, 8 Nov 2012 13:40:51 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 011E221F8860 for ; Thu, 8 Nov 2012 13:40:50 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2519E16C004; Thu, 8 Nov 2012 22:40:50 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 16F4F16C002; Thu, 8 Nov 2012 22:40:50 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Nov 2012 22:40:49 +0100 Received: from [10.193.116.63] ([10.193.116.63]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Nov 2012 22:40:49 +0100 Message-ID: <509C26DD.3000107@orange.com> Date: Thu, 08 Nov 2012 22:40:45 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: =?windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> In-Reply-To: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2012 21:40:49.0366 (UTC) FILETIME=[B7E99F60:01CDBDF9] Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:40:52 -0000 Oscar, all, There are multiple issues in your messages, let us try to address them step by step. About the adoption of draft-crabbe-pce-stateful-pce, your choice of words suggests that you are taxing the chairs of a process failure in building a WG consensus. However, you finally agree not only that the consensus was there (and rather clear than rough), and also that you were yourself a supporter of the I-D. Please, try to carefully choose your wording to avoid misunderstanding. I would also like to remind you 2 things: - we are not talking about an RFC nor even an I-D in LC: it is part of the normal WG process to discuss documents so as to progress them; - as mentioned previously (http://www.ietf.org/mail-archive/web/pce/current/msg02738.html), what was adopted by the WG was an I-D with a defined (and limited) scope; from that point, it seems that there is a certain will to embrace everything that could be tagged "stateful", however we need to limit our scope of work (architecture and charter) to a reasonable problem space. Then, concerning our current scope, you certainly should have a fresh look at RFC 4655. E.g., section 6.12: "It may be that the PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction.[...] Additionally, the protocol could be used to collect and report information in support of a stateful PCE." We are not machines, but as chairs, we consider that the original draft-crabbe-pce-stateful-pce, which was adopted by the WG, was consistent with this statement (which, since included in an RFC, passed IESG review). Now, let us look at the figure 2 in section 5.2 of the very same RFC. The service request is directed to the head-node, and to the head-node only. This means that our _current_ architecture does not cover the case where this service request is sent to a "PCE-tagged box", no matter how close the technical solutions for both functions might be. One may argue that the service request towards the head-node might come from the "PCE-tagged box", and thus use PCEP, but some response lies in section 5.5 (figure 5): the service request is identified as different from PCEP, even if we pack the NMS and the PCE into a common box, and the 1st service request always comes from the outside (e.g. the operator). As you are aware, one of the outputs from our meeting this week was to consider an update to the architecture and charter, so as to reflect the areas where the WG wants to head to. Note that, at one point, this will have to be discussed with the IESG (starting by our AD). If you have ideas to propose (and I'm sure you aren't the only one), then you should start to write that architectural draft you mention: it will be a useful element to bring to that discussion, especially because we need to identify the functional blocks we are talking about. As highlighted by Adrian (http://www.ietf.org/mail-archive/web/pce/current/msg02722.html), "we have previously found that scoping the PCE work to well-understood and contained problem spaces [...] has made our work concrete and functional" (and also eases charter approval by the IESG); therefore the WG needs to discuss in order to identify a possible update of its scope. Thanks for sharing your thoughts on the list, this is needed to move forward. Julien On 11/07/2012 23:04, Oscar Gonz�lez de Dios wrote: > > Dear PCE WG chairs, > > > > In the last PCE meeting, it was mentioned by the WG chairs that the > function of LSP initiation by the PCE (presented in the draft > draft-crabbe-pce-pce-initiated-lsp-00) is out of the scope of current > WG charter. Current IETF stateful PCE draft () supports the function > of delegation, which is an operation to grant a PCE temporary rights > to modify a subset of tunnel parameters on one or more PCC's tunnels. > However, current charter > (http://datatracker.ietf.org/wg/pce/charter/) says nothing about this > function, but the draft was (surprisingly) quickly accepted as WG > document. Current charter says �The PCE Working Group is chartered to > specify the required protocols so as to enable a Path Computation > Element (PCE)-based architecture for the computation of paths for > MPLS and GMPLS Point to Point and Point to Multi-point Traffic > Engineered LSPs.� That is �computation�, not control� So, could you > explain why initiation is not in charter and delegation of control is > in charter? > > > > My opinion in the matter of the stateful PCE is that we should > separate the functionality is different functional elements, in the > same way as it was done in the Framework for PCE-Based Inter-Layer > MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the > PCE. In such RFC, the roles of each functional element are clearly > distinguished. Let be the stateful PCE a Path Computation element > using the traffic engineering database and the LSP database, and > then, define another functional element (call it LSP controller, call > it manager) that is in care of the control issues. > > > > Said that, I must say that I like the new functionalities proposed , > and I think they solve problems (and people also did like them, as > the stateful draft was supported by the WG people). What I do not > like at all is how it is being handled. There has been a solution > quickly adopted without taking any care in the > architectural/functional implications. In my opinion we should handle > them now. > > > > Best Regards, > > > > �scar > > > > > > > > > > > ------------------------- > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra pol�tica de env�o y recepci�n de correo electr�nico > en el enlace situado m�s abajo. This message is intended exclusively > for its addressee. We only send and receive email on the basis of the > terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > _______________________________________________ Pce mailing list > Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ogondio@tid.es Thu Nov 8 14:28:27 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D459F21F8786 for ; Thu, 8 Nov 2012 14:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.443 X-Spam-Level: X-Spam-Status: No, score=-4.443 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] 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 opvvpdtcYmeq for ; Thu, 8 Nov 2012 14:28:27 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D89521F84D3 for ; Thu, 8 Nov 2012 14:28:26 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MD6002MXX38E3@tid.hi.inet> for pce@ietf.org; Thu, 08 Nov 2012 23:28:20 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 6E.46.03143.4023C905; Thu, 08 Nov 2012 23:28:20 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MD6002MTX38E3@tid.hi.inet> for pce@ietf.org; Thu, 08 Nov 2012 23:28:20 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Thu, 08 Nov 2012 23:28:19 +0100 Date: Thu, 08 Nov 2012 22:28:19 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: <509C26DD.3000107@orange.com> X-Originating-IP: [10.95.64.115] To: Julien Meuric Message-id: <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-index: AQHNvfnEhZaesskiakSuPcRZYV/YoJfgexzQ X-AuditID: 0a5f4068-b7f746d000000c47-60-509c3204476a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXCFe/ApctiNCfA4EyPsEXT/RvsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOPFkD2vBD7GKy2+72RoYDwl1MXJySAiYSNz4tJMJwhaTuHBv PVsXIxeHkMAGRonHH2+yQDjfGCVaO46yQzjTGCU+vrzEAtLCIqAqcbulkxXEZhNwkFi3qJcN xBYWyJCYOHs3O4jNKaAlsae5nw1ihYLEn3OPwXpFBHQkzr8/A1TDwcEsoCjx7jYvSJhXwFti z6dJbBC2oMSPyffAypmBynu/f2OGsMUl5vyayApha0s8eXcBzGYUkJVYef40I8T4TIk3Da1M ELaRxMUb69khThCQWLLnPDOELSrx8vE/sF4hgWyJGR/b2Scwis9CsnoWktWzkKyehWT1AkaW VYxixUlFmekZJbmJmTnpBoZ6GZl6mXmpJZsYIXGUsYNx+U6VQ4wCHIxKPLw3MmYHCLEmlhVX 5h5ilORgUhLlXWIwJ0CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG8dE1CONyWxsiq1KB8mJcPB oSTB2wrSJliUmp5akZaZA0wWMGkmDk6Qdh6g9kMgNbzFBYm5xZnpEPlTjNocO3cufMjIsesz kBRiycvPS5US560FKRUAKc0ozYOb9opRHOhsYd69IFkeYOqDm/MKaAUT0IriazNAVpQkIqSk GhhZiiy/frmRsY2n4GPI3oalX21LNZy+pUUEtJTmhCp//Py07FCzme+W4yz9qXtk/v6NmHrV T+1RLiuzzrP1f7yMNv3O7/srvyPhgzunisvm7Us/l7tO9IouXnlfNkH08MnQ/4WTDk5o9fm6 Kmpdzcsk7jj/0z9VP2ZfXVd7659trZF1Gnuuh4ESS3FGoqEWc1FxIgAFWWzsOgMAAA== References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 22:28:28 -0000 Hi Julien Thanks for the reply. As you said, there where several parts of the= message. I will now limit to cover the discussion of the scope of LSP dele= gation and LSP incitation procedures in the charter. For the rest, I will r= eply in separate mails, in private if you want, in sake of advancing the di= scussions, and my apologies if my words have been misunderstood or sounded = harsh. Comments inline "Then, concerning our current scope, you certainly should have a fresh look= at RFC 4655. E.g., section 6.12: "It may be that the PCC-PCE communications (see Section 6.6) can be usefull= y extended beyond a simple request/response interaction.[...] Additionally,= the protocol could be used to collect and report information in support of= a stateful PCE." We are not machines, but as chairs, we consider that the original draft-cra= bbe-pce-stateful-pce, which was adopted by the WG, was consistent with this= statement (which, since included in an RFC, passed IESG review)." [Oscar]: The state synchronization functions, aimed at (citing literally) = provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE ar= e consistent with this statement, they are beyond simple request/response i= nteractions and collect and report information in support of a stateful PCE= . Thus, this function is perfectly OK with RFC 4555. However, I see that the LSP delegation function goes beyond reporting infor= mation to support a stateful PCE. It instructs the PCE to take control of t= he LSP, and, during the life-time of the LSP, citing literally "the PCC gra= nts to a PCE the right to update LSP attributes on one or more LSPs; the PC= E becomes the authoritative source of the LSP's attributes as long as the d= elegation is in effect". Thus, delegation function clearly is not used to p= rovide information to support later path computation. So... unless I have m= istaken the read of RFC 4655, it is explicitly mentioned that the PCE archi= tecture is aimed at solving the problem of path computation. I may have jum= ped over some paragraph where it says that the role of a Path Computation E= lement (stateful o not stateful) is to take care of the control of an LSP..= . but I honestly cannot find such statement anywhere. So... could you give = me some arguments why the delegation of control is in scope of current RFC = 4655? (Of course the scope can be widened in future, so let's try to stick = to current RFC 4655) Best Regards, =D3scar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From jmedved@cisco.com Thu Nov 8 17:11:48 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961D921F853D for ; Thu, 8 Nov 2012 17:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.487 X-Spam-Level: X-Spam-Status: No, score=-8.487 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812] 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 RwVydtQ0eSvG for ; Thu, 8 Nov 2012 17:11:42 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E17CB21F8552 for ; Thu, 8 Nov 2012 17:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4509; q=dns/txt; s=iport; t=1352423502; x=1353633102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OocwpI+kcG7GMORVrJg42zrLbESuyDbuSS082BfYggM=; b=X34L50IaTdPiYsStwKZ3hbETnjHLicoAKiJWwk87MZSZ9/lvloEIM6Ml iq6g++FZJ74uSA/quOydemoH0QnzBAoCvor3bR1jR9DOP1jfSZT+M67Jp lKUfT110mz4a250CAbqi3AX+Pf36u6BUmHsVA+vWoLT9u9PSyyTXmJ55K o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACFYnFCtJXG//2dsb2JhbABEw0KBCIIeAQEBAwESAV8HBQsCAQgSECQyFw4CBA4NEQmHYgacP6AjjBIUhVJhA4glnC6Ba4JvgVsgAhw X-IronPort-AV: E=Sophos;i="4.80,741,1344211200"; d="scan'208";a="140370262" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 09 Nov 2012 01:11:41 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA91BfSx024674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 01:11:41 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 19:11:40 -0600 From: "Jan Medved (jmedved)" To: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: AQHNvfm+UUvGR5C2qEyyx5swx2GPe5fg6VaAgAAtpAA= Date: Fri, 9 Nov 2012 01:11:40 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> In-Reply-To: <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.165] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--44.455900-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: <63C4427D90C7934BAF206E6BFF93E5E4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 01:11:48 -0000 Hi Oscar, please see inline. On Nov 8, 2012, at 2:28 PM, Oscar Gonz=E1lez de Dios wrote: > [Oscar]: The state synchronization functions, aimed at (citing literally)= provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE = are consistent with this statement, they are beyond simple request/response= interactions and collect and report information in support of a stateful P= CE. Thus, this function is perfectly OK with RFC 4555. >=20 > However, I see that the LSP delegation function goes beyond reporting inf= ormation to support a stateful PCE. It instructs the PCE to take control of= the LSP, and, during the life-time of the LSP, citing literally "the PCC g= rants to a PCE the right to update LSP attributes on one or more LSPs; the = PCE becomes the authoritative source of the LSP's attributes as long as the= delegation is in effect". Thus, delegation function clearly is not used to= provide information to support later path computation. So... unless I have= mistaken the read of RFC 4655, it is explicitly mentioned that the PCE arc= hitecture is aimed at solving the problem of path computation. The PCE is not limited to path computation only. The PCE can set other LSP = parameters as well: RFC5440 defines objects for bandwidth, setup & hold pri= orities, the local protection flag, etc. More LSP parameters have been adde= d in subsequent RFCs and drafts. =20 > I may have jumped over some paragraph where it says that the role of a Pa= th Computation Element (stateful o not stateful) is to take care of the con= trol of an LSP... but I honestly cannot find such statement anywhere. So...= could you give me some arguments why the delegation of control is in scope= of current RFC 4655? The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC= sends a PCReq message to a PCE requesting path computation (and parameter = setting) for an LSP, it effectively delegates control over that LSP to the = PCE. The delegation is valid for one request (and one path computation) onl= y.=20 Now, the PCC may or may not use the LSP path/parameters that it got from th= e PCE. But why would the PCC not use the PCE-computed path & parameters, if= we want the whole scheme to work? The PCC goes to the PCE for LSP path bec= ause the PCE can do a better job at path computation (and LSP parameter set= ting) that the PCC itself. The PCC would only throw away the PCE-computed L= SP parameters if there was an error condition and the LSP could not be esta= blished (the PCC may in this case compute the path locally). So there is delegation in 4655, although it's implicit. Delegation is not s= o obvious for stateless PCEs - basically, a if PCC does not use a PCE-compu= ted path, the impact on the stateless PCE and its path computations for oth= er PCCs is not big, because the stateless PCE does not keep track of LSPs.= =20 The delegation concept is a lot stronger for stateful PCEs, where strict st= ate synchronization between a PCC and a PCE is required. RFC4655 Section 6.= 8 states: "there is a strict synchronization between the PCE and not only t= he network states (in term of topology and resource information), but also = the set of computed paths and reserved resources in use in the network." So= if a PCC does not use the path computed by the PCE, it must notify the PCE= , and also tell it about the path/parameters that were used for the LSP. Th= is points at a tighter PCE control by a PCE over a PCC's LSPs, which in tur= n requires stronger delegation. In draft-ietf-pce-stateful-pce we had to make delegation explicit, because = the PCE controls the timing of LSP setups/teardowns. So, when a PCC is read= y to accept PCE's path computations and LSP setups, it *explicitly* delegat= es its LSPs to the PCE. Note that the PCC still owns all its LSPs, and can = withdraw the LSP delegation from a PCE at any time. If a PCC decides not to= use LSP path/parameters computed by a PCE - it can still do it, just like = in the above cases. It simply revokes the LSP delegation from the PCE and d= oes whatever it wants with the LSP. However, since it is a stateful PCC, it= still MUST tell the PCE what it has done (sending a PCReport for the LSP). > (Of course the scope can be widened in future, so let's try to stick to c= urrent RFC 4655) As outlined above, IMO draft-ietf-pce-stateful-pce is compliant with RFC465= 5. Thanks, Jan From zhangfatai@huawei.com Fri Nov 9 00:21:05 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA44121F8BA2 for ; Fri, 9 Nov 2012 00:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.728 X-Spam-Level: * X-Spam-Status: No, score=1.728 tagged_above=-999 required=5 tests=[AWL=-2.873, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812, 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 qvf2eCPZliEQ for ; Fri, 9 Nov 2012 00:21:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8B8F21F8B7A for ; Fri, 9 Nov 2012 00:21:03 -0800 (PST) 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 AMO38113; Fri, 09 Nov 2012 08:20:44 +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; Fri, 9 Nov 2012 08:20:27 +0000 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 9 Nov 2012 08:20:42 +0000 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.134]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Fri, 9 Nov 2012 16:20:40 +0800 From: Fatai Zhang To: "Jan Medved (jmedved)" , =?gb2312?B?T3NjYXIgR29ueqiibGV6IGRlIERpb3M=?= Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: Ac29M0Ug4djLg+GXRUWVnAOlC+tbMAAg2IOAAAGpR4AABbR2AAAfI24Q Date: Fri, 9 Nov 2012 08:20:39 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.85] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF82D6874E1SZXEML552MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] =?gb2312?b?tPC4tDogIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0Us?= =?gb2312?b?IHJlbGF0aW9uIHRvIFdHIGNoYXJ0ZXIgYW5kIG9waW5pb24gYWJvdXQgc3Rh?= =?gb2312?b?dGVmdWwgUENF?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 08:21:05 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF82D6874E1SZXEML552MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQoNCg0KPlRoZSBQQ0UgaXMgbm90IGxpbWl0ZWQgdG8gcGF0aCBjb21wdXRhdGlv biBvbmx5LiBUaGUgUENFIGNhbiBzZXQgb3RoZXIgTFNQIHBhcmFtZXRlcnMgYXMgd2VsbDogUkZD NTQ0MCBkZWZpbmVzIG9iamVjdHMgZm9yIGJhbmR3aWR0aCwgc2V0dXAgJiBob2xkIHByaW9yaXRp ZXMsIHRoZSBsb2NhbCBwcm90ZWN0aW9uIGZsYWcsIGV0Yy4gTW9yZSBMU1AgcGFyYW1ldGVycyBo YXZlIGJlZW4gYWRkZWQgaW4gc3Vic2VxdWVudCBSRkNzIGFuZCBkcmFmdHMuDQoNCg0KDQpbRmF0 YWldIEkgaGF2ZSB0byBpbmRpY2F0ZSB0aGF0IFBDRSBjYW5ub3QgKnNldCogb3RoZXIgTFNQIHBh cmFtZXRlcnMuIFRoZSBwYXJhbWV0ZXJzIChlZy4sIGJhbmR3aWR0aCwgcHJpb3JpdGllcywgZXRj KSB5b3UgbWVudGlvbmVkIGFyZSBvbmx5IHVzZWQgZm9yICpwYXRoIGNvbXB1dGF0aW9uKi4NCg0K DQoNCj4+IEkgbWF5IGhhdmUganVtcGVkIG92ZXIgc29tZSBwYXJhZ3JhcGggd2hlcmUgaXQgc2F5 cyB0aGF0IHRoZSByb2xlIG9mIGEgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IChzdGF0ZWZ1bCBv IG5vdCBzdGF0ZWZ1bCkgaXMgdG8gdGFrZSBjYXJlIG9mIHRoZSBjb250cm9sIG9mIGFuIExTUC4u LiBidXQgSSBob25lc3RseSBjYW5ub3QgZmluZCBzdWNoIHN0YXRlbWVudCBhbnl3aGVyZS4gU28u Li4gY291bGQgeW91IGdpdmUgbWUgc29tZSBhcmd1bWVudHMgd2h5IHRoZSBkZWxlZ2F0aW9uIG9m IGNvbnRyb2wgaXMgaW4gc2NvcGUgb2YgY3VycmVudCBSRkMgNDY1NT8NCg0KDQoNCj5UaGUgZGVs ZWdhdGlvbiBvZiBMU1AgY29udHJvbCB0byBhIFBDRSBpcyAqaW1wbGljaXQqIGluIFJGQzQ2NTUu IFdoZW4gYSBQQ0Mgc2VuZHMgYSBQQ1JlcSBtZXNzYWdlIHRvIGEgUENFIHJlcXVlc3RpbmcgcGF0 aCBjb21wdXRhdGlvbiAoYW5kIHBhcmFtZXRlciBzZXR0aW5nKSBmb3IgYW4gTFNQLCBpdCBlZmZl Y3RpdmVseQ0KDQo+IGRlbGVnYXRlcyBjb250cm9sIG92ZXIgdGhhdCBMU1AgdG8gdGhlIFBDRS4g VGhlIGRlbGVnYXRpb24gaXMgdmFsaWQgZm9yIG9uZSByZXF1ZXN0IChhbmQgb25lIHBhdGggY29t cHV0YXRpb24pIG9ubHkuDQoNCg0KDQpbRmF0YWldIEkgZG9uJ3QgdGhpbmsgdGhhdCBSRkM0NjU1 IGNhbiBzdXBwb3J0IGRlbGVnYXRpb24gb2YgTFNQICpjb250cm9sKiAoZXZlbiBpbXBsaWNpdGx5 KS4gQSBQQ0Mgc2VuZHMgYSBQQ1JlcSB0byBhIFBDRSwgaXQgZG9lcyBub3QgbWVhbiB0aGF0IHRo aXMgTFNQIGlzIGRlbGVnYXRlZCB0byB0aGUgUENFLg0KDQoNCg0KDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMNCg0KDQoNCkZhdGFpDQoNCg0KDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHBj ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSmFu IE1lZHZlZCAoam1lZHZlZCkNCreiy83KsbzkOiAyMDEyxOoxMdTCOcjVIDk6MTINCsrVvP7Iyzog T3NjYXIgR29ueqiibGV6IGRlIERpb3MNCrOty806IHBjZUBpZXRmLm9yZw0K1vfM4jogUmU6IFtQ Y2VdIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0UsIHJlbGF0aW9uIHRvIFdHIGNoYXJ0ZXIg YW5kIG9waW5pb24gYWJvdXQgc3RhdGVmdWwgUENFDQoNCg0KDQpIaSBPc2NhciwNCg0KDQoNCnBs ZWFzZSBzZWUgaW5saW5lLg0KDQoNCg0KT24gTm92IDgsIDIwMTIsIGF0IDI6MjggUE0sIE9zY2Fy IEdvbnqoomxleiBkZSBEaW9zIHdyb3RlOg0KDQoNCg0KPiBbT3NjYXJdOiBUaGUgc3RhdGUgc3lu Y2hyb25pemF0aW9uIGZ1bmN0aW9ucywgYWltZWQgYXQgKGNpdGluZyBsaXRlcmFsbHkpICBwcm92 aWRlIGEgY2hlY2twb2ludC1pbi10aW1lIHN0YXRlIHJlcGxpY2Egb2YgYSBQQ0MncyBMU1Agc3Rh dGUgaW4gYSBQQ0UgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGlzIHN0YXRlbWVudCwgdGhleSBhcmUg YmV5b25kIHNpbXBsZSByZXF1ZXN0L3Jlc3BvbnNlIGludGVyYWN0aW9ucyBhbmQgY29sbGVjdCBh bmQgcmVwb3J0IGluZm9ybWF0aW9uIGluIHN1cHBvcnQgb2YgYSBzdGF0ZWZ1bCBQQ0UuIFRodXMs IHRoaXMgZnVuY3Rpb24gaXMgcGVyZmVjdGx5IE9LIHdpdGggUkZDIDQ1NTUuDQoNCj4NCg0KPiBI b3dldmVyLCBJIHNlZSB0aGF0IHRoZSBMU1AgZGVsZWdhdGlvbiBmdW5jdGlvbiBnb2VzIGJleW9u ZCByZXBvcnRpbmcgaW5mb3JtYXRpb24gdG8gc3VwcG9ydCBhIHN0YXRlZnVsIFBDRS4gSXQgaW5z dHJ1Y3RzIHRoZSBQQ0UgdG8gdGFrZSBjb250cm9sIG9mIHRoZSBMU1AsIGFuZCwgZHVyaW5nIHRo ZSBsaWZlLXRpbWUgb2YgdGhlIExTUCwgY2l0aW5nIGxpdGVyYWxseSAidGhlIFBDQyBncmFudHMg dG8gYSBQQ0UgdGhlIHJpZ2h0IHRvIHVwZGF0ZSBMU1AgYXR0cmlidXRlcyBvbiBvbmUgb3IgbW9y ZSBMU1BzOyB0aGUgUENFIGJlY29tZXMgdGhlIGF1dGhvcml0YXRpdmUgc291cmNlIG9mIHRoZSBM U1AncyBhdHRyaWJ1dGVzIGFzIGxvbmcgYXMgdGhlIGRlbGVnYXRpb24gaXMgaW4gZWZmZWN0Ii4g VGh1cywgZGVsZWdhdGlvbiBmdW5jdGlvbiBjbGVhcmx5IGlzIG5vdCB1c2VkIHRvIHByb3ZpZGUg aW5mb3JtYXRpb24gdG8gc3VwcG9ydCBsYXRlciBwYXRoIGNvbXB1dGF0aW9uLiBTby4uLiB1bmxl c3MgSSBoYXZlIG1pc3Rha2VuIHRoZSByZWFkIG9mIFJGQyA0NjU1LCBpdCBpcyBleHBsaWNpdGx5 IG1lbnRpb25lZCB0aGF0IHRoZSBQQ0UgYXJjaGl0ZWN0dXJlIGlzIGFpbWVkIGF0IHNvbHZpbmcg dGhlIHByb2JsZW0gb2YgcGF0aCBjb21wdXRhdGlvbi4NCg0KDQoNClRoZSBQQ0UgaXMgbm90IGxp bWl0ZWQgdG8gcGF0aCBjb21wdXRhdGlvbiBvbmx5LiBUaGUgUENFIGNhbiBzZXQgb3RoZXIgTFNQ IHBhcmFtZXRlcnMgYXMgd2VsbDogUkZDNTQ0MCBkZWZpbmVzIG9iamVjdHMgZm9yIGJhbmR3aWR0 aCwgc2V0dXAgJiBob2xkIHByaW9yaXRpZXMsIHRoZSBsb2NhbCBwcm90ZWN0aW9uIGZsYWcsIGV0 Yy4gTW9yZSBMU1AgcGFyYW1ldGVycyBoYXZlIGJlZW4gYWRkZWQgaW4gc3Vic2VxdWVudCBSRkNz IGFuZCBkcmFmdHMuDQoNCj4gSSBtYXkgaGF2ZSBqdW1wZWQgb3ZlciBzb21lIHBhcmFncmFwaCB3 aGVyZSBpdCBzYXlzIHRoYXQgdGhlIHJvbGUgb2YgYSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQg KHN0YXRlZnVsIG8gbm90IHN0YXRlZnVsKSBpcyB0byB0YWtlIGNhcmUgb2YgdGhlIGNvbnRyb2wg b2YgYW4gTFNQLi4uIGJ1dCBJIGhvbmVzdGx5IGNhbm5vdCBmaW5kIHN1Y2ggc3RhdGVtZW50IGFu eXdoZXJlLiBTby4uLiBjb3VsZCB5b3UgZ2l2ZSBtZSBzb21lIGFyZ3VtZW50cyB3aHkgdGhlIGRl bGVnYXRpb24gb2YgY29udHJvbCBpcyBpbiBzY29wZSBvZiBjdXJyZW50IFJGQyA0NjU1Pw0KDQoN Cg0KVGhlIGRlbGVnYXRpb24gb2YgTFNQIGNvbnRyb2wgdG8gYSBQQ0UgaXMgKmltcGxpY2l0KiBp biBSRkM0NjU1LiBXaGVuIGEgUENDIHNlbmRzIGEgUENSZXEgbWVzc2FnZSB0byBhIFBDRSByZXF1 ZXN0aW5nIHBhdGggY29tcHV0YXRpb24gKGFuZCBwYXJhbWV0ZXIgc2V0dGluZykgZm9yIGFuIExT UCwgaXQgZWZmZWN0aXZlbHkgZGVsZWdhdGVzIGNvbnRyb2wgb3ZlciB0aGF0IExTUCB0byB0aGUg UENFLiBUaGUgZGVsZWdhdGlvbiBpcyB2YWxpZCBmb3Igb25lIHJlcXVlc3QgKGFuZCBvbmUgcGF0 aCBjb21wdXRhdGlvbikgb25seS4NCg0KDQoNCk5vdywgdGhlIFBDQyBtYXkgb3IgbWF5IG5vdCB1 c2UgdGhlIExTUCBwYXRoL3BhcmFtZXRlcnMgdGhhdCBpdCBnb3QgZnJvbSB0aGUgUENFLiBCdXQg d2h5IHdvdWxkIHRoZSBQQ0Mgbm90IHVzZSB0aGUgUENFLWNvbXB1dGVkIHBhdGggJiBwYXJhbWV0 ZXJzLCBpZiB3ZSB3YW50IHRoZSB3aG9sZSBzY2hlbWUgdG8gd29yaz8gVGhlIFBDQyBnb2VzIHRv IHRoZSBQQ0UgZm9yIExTUCBwYXRoIGJlY2F1c2UgdGhlIFBDRSBjYW4gZG8gYSBiZXR0ZXIgam9i IGF0IHBhdGggY29tcHV0YXRpb24gKGFuZCBMU1AgcGFyYW1ldGVyIHNldHRpbmcpIHRoYXQgdGhl IFBDQyBpdHNlbGYuIFRoZSBQQ0Mgd291bGQgb25seSB0aHJvdyBhd2F5IHRoZSBQQ0UtY29tcHV0 ZWQgTFNQIHBhcmFtZXRlcnMgaWYgdGhlcmUgd2FzIGFuIGVycm9yIGNvbmRpdGlvbiBhbmQgdGhl IExTUCBjb3VsZCBub3QgYmUgZXN0YWJsaXNoZWQgKHRoZSBQQ0MgbWF5IGluIHRoaXMgY2FzZSBj b21wdXRlIHRoZSBwYXRoIGxvY2FsbHkpLg0KDQoNCg0KU28gdGhlcmUgaXMgZGVsZWdhdGlvbiBp biA0NjU1LCBhbHRob3VnaCBpdCdzIGltcGxpY2l0LiBEZWxlZ2F0aW9uIGlzIG5vdCBzbyBvYnZp b3VzIGZvciBzdGF0ZWxlc3MgUENFcyAtIGJhc2ljYWxseSwgYSBpZiBQQ0MgZG9lcyBub3QgdXNl IGEgUENFLWNvbXB1dGVkIHBhdGgsIHRoZSBpbXBhY3Qgb24gdGhlIHN0YXRlbGVzcyBQQ0UgYW5k IGl0cyBwYXRoIGNvbXB1dGF0aW9ucyBmb3Igb3RoZXIgUENDcyBpcyBub3QgYmlnLCBiZWNhdXNl IHRoZSBzdGF0ZWxlc3MgUENFIGRvZXMgbm90IGtlZXAgdHJhY2sgb2YgTFNQcy4NCg0KDQoNClRo ZSBkZWxlZ2F0aW9uIGNvbmNlcHQgaXMgYSBsb3Qgc3Ryb25nZXIgZm9yIHN0YXRlZnVsIFBDRXMs IHdoZXJlIHN0cmljdCBzdGF0ZSBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhIFBDQyBhbmQgYSBQ Q0UgaXMgcmVxdWlyZWQuIFJGQzQ2NTUgU2VjdGlvbiA2Ljggc3RhdGVzOiAidGhlcmUgaXMgYSBz dHJpY3Qgc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlIFBDRSBhbmQgbm90IG9ubHkgdGhlIG5l dHdvcmsgc3RhdGVzIChpbiB0ZXJtIG9mIHRvcG9sb2d5IGFuZCByZXNvdXJjZSBpbmZvcm1hdGlv biksIGJ1dCBhbHNvIHRoZSBzZXQgb2YgY29tcHV0ZWQgcGF0aHMgYW5kIHJlc2VydmVkIHJlc291 cmNlcyBpbiB1c2UgaW4gdGhlIG5ldHdvcmsuIiBTbyBpZiBhIFBDQyBkb2VzIG5vdCB1c2UgdGhl IHBhdGggY29tcHV0ZWQgYnkgdGhlIFBDRSwgaXQgbXVzdCBub3RpZnkgdGhlIFBDRSwgYW5kIGFs c28gdGVsbCBpdCBhYm91dCB0aGUgcGF0aC9wYXJhbWV0ZXJzIHRoYXQgd2VyZSB1c2VkIGZvciB0 aGUgTFNQLiBUaGlzIHBvaW50cyBhdCBhIHRpZ2h0ZXIgUENFIGNvbnRyb2wgYnkgYSBQQ0Ugb3Zl ciBhIFBDQydzIExTUHMsIHdoaWNoIGluIHR1cm4gcmVxdWlyZXMgc3Ryb25nZXIgZGVsZWdhdGlv bi4NCg0KDQoNCkluIGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZSB3ZSBoYWQgdG8gbWFrZSBk ZWxlZ2F0aW9uIGV4cGxpY2l0LCBiZWNhdXNlIHRoZSBQQ0UgY29udHJvbHMgdGhlIHRpbWluZyBv ZiBMU1Agc2V0dXBzL3RlYXJkb3ducy4gU28sIHdoZW4gYSBQQ0MgaXMgcmVhZHkgdG8gYWNjZXB0 IFBDRSdzIHBhdGggY29tcHV0YXRpb25zIGFuZCBMU1Agc2V0dXBzLCBpdCAqZXhwbGljaXRseSog ZGVsZWdhdGVzIGl0cyBMU1BzIHRvIHRoZSBQQ0UuIE5vdGUgdGhhdCB0aGUgUENDIHN0aWxsIG93 bnMgYWxsIGl0cyBMU1BzLCBhbmQgY2FuIHdpdGhkcmF3IHRoZSBMU1AgZGVsZWdhdGlvbiBmcm9t IGEgUENFIGF0IGFueSB0aW1lLiBJZiBhIFBDQyBkZWNpZGVzIG5vdCB0byB1c2UgTFNQIHBhdGgv cGFyYW1ldGVycyBjb21wdXRlZCBieSBhIFBDRSAtIGl0IGNhbiBzdGlsbCBkbyBpdCwganVzdCBs aWtlIGluIHRoZSBhYm92ZSBjYXNlcy4gSXQgc2ltcGx5IHJldm9rZXMgdGhlIExTUCBkZWxlZ2F0 aW9uIGZyb20gdGhlIFBDRSBhbmQgZG9lcyB3aGF0ZXZlciBpdCB3YW50cyB3aXRoIHRoZSBMU1Au IEhvd2V2ZXIsIHNpbmNlIGl0IGlzIGEgc3RhdGVmdWwgUENDLCBpdCBzdGlsbCBNVVNUIHRlbGwg dGhlIFBDRSB3aGF0IGl0IGhhcyBkb25lIChzZW5kaW5nIGEgUENSZXBvcnQgZm9yIHRoZSBMU1Ap Lg0KDQoNCg0KDQoNCj4gKE9mIGNvdXJzZSB0aGUgc2NvcGUgY2FuIGJlIHdpZGVuZWQgaW4gZnV0 dXJlLCBzbyBsZXQncyB0cnkgdG8gc3RpY2sgdG8gY3VycmVudCBSRkMgNDY1NSkNCg0KDQoNCkFz IG91dGxpbmVkIGFib3ZlLCBJTU8gZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlIGlzIGNvbXBs aWFudCB3aXRoIFJGQzQ2NTUuDQoNCg0KDQoNCg0KDQoNCg0KDQpUaGFua3MsDQoNCkphbg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUGNl IG1haWxpbmcgbGlzdA0KDQpQY2VAaWV0Zi5vcmcNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wY2UNCg== --_000_F82A4B6D50F9464B8EBA55651F541CF82D6874E1SZXEML552MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jan,

>The PCE is not limited t= o path computation only. The PCE can set other LSP parameters as well: RFC5= 440 defines objects for bandwidth, setup & hold priorities, the local p= rotection flag, etc. More LSP parameters have been added in subsequent RFCs and drafts.

[Fat= ai] I have to indicate that PCE cannot *set* other LSP parameters. The para= meters (eg., bandwidth, priorities, etc) you mentioned are only used for *p= ath computation*.

>> I may have jumped o= ver some paragraph where it says that the role of a Path Computation Elemen= t (stateful o not stateful) is to take care of the control of an LSP... but= I honestly cannot find such statement anywhere. So... could you give me some arguments why the delegation of control is in= scope of current RFC 4655?

>The delegation of LSP co= ntrol to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message t= o a PCE requesting path computation (and parameter setting) for an LSP, it = effectively

> delegates control over = that LSP to the PCE. The delegation is valid for one request (and one path = computation) only.

[Fat= ai] I don't think that RFC4655 can support delegation of LSP *control* (eve= n implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP= is delegated to the PCE.

Best Regards

Fatai

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] =B4=FA=B1=ED Jan Medved (jmedved)
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C29=C8=D5 9:12
=CA=D5=BC=FE=C8=CB: Oscar Gonz=A8=A2lez de Dios
=B3=AD=CB=CD: pce@ietf.org
=D6=F7=CC=E2: Re: [Pce] Questions about stateful PCE, relation to WG chart= er and opinion about stateful PCE

Hi Oscar,<= /p>

please see inline.

On Nov 8, 2012, at 2:28 PM, = Oscar Gonz=A8=A2lez de Dios wrote:

> [Oscar]: The state sync= hronization functions, aimed at (citing literally) provide a checkpoi= nt-in-time state replica of a PCC's LSP state in a PCE are consistent with = this statement, they are beyond simple request/response interactions and collect and report information in support of a stateful P= CE. Thus, this function is perfectly OK with RFC 4555.

> However, I see that the= LSP delegation function goes beyond reporting information to support a sta= teful PCE. It instructs the PCE to take control of the LSP, and, during the= life-time of the LSP, citing literally "the PCC grants to a PCE the right to update LSP attributes on one or= more LSPs; the PCE becomes the authoritative source of the LSP's attribute= s as long as the delegation is in effect". Thus, delegation function c= learly is not used to provide information to support later path computation. So... unless I have mistaken the read o= f RFC 4655, it is explicitly mentioned that the PCE architecture is aimed a= t solving the problem of path computation.

The PCE is not limited to pa= th computation only. The PCE can set other LSP parameters as well: RFC5440 = defines objects for bandwidth, setup & hold priorities, the local prote= ction flag, etc. More LSP parameters have been added in subsequent RFCs and drafts.

> I may have jumped over = some paragraph where it says that the role of a Path Computation Element (s= tateful o not stateful) is to take care of the control of an LSP... but I h= onestly cannot find such statement anywhere. So... could you give me some arguments why the delegation of control is in= scope of current RFC 4655?

The delegation of LSP contro= l to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message to a = PCE requesting path computation (and parameter setting) for an LSP, it effe= ctively delegates control over that LSP to the PCE. The delegation is valid for one request (and one path comp= utation) only.

Now, the PCC may or may not = use the LSP path/parameters that it got from the PCE. But why would the PCC= not use the PCE-computed path & parameters, if we want the whole schem= e to work? The PCC goes to the PCE for LSP path because the PCE can do a better job at path computation (and LSP para= meter setting) that the PCC itself. The PCC would only throw away the PCE-c= omputed LSP parameters if there was an error condition and the LSP could no= t be established (the PCC may in this case compute the path locally).

So there is delegation in 46= 55, although it's implicit. Delegation is not so obvious for stateless PCEs= - basically, a if PCC does not use a PCE-computed path, the impact on the = stateless PCE and its path computations for other PCCs is not big, because the stateless PCE does not keep track o= f LSPs.

The delegation concept is a = lot stronger for stateful PCEs, where strict state synchronization between = a PCC and a PCE is required. RFC4655 Section 6.8 states: "there is a s= trict synchronization between the PCE and not only the network states (in term of topology and resource information)= , but also the set of computed paths and reserved resources in use in the n= etwork." So if a PCC does not use the path computed by the PCE, it mus= t notify the PCE, and also tell it about the path/parameters that were used for the LSP. This points at a tighter P= CE control by a PCE over a PCC's LSPs, which in turn requires stronger dele= gation.

In draft-ietf-pce-stateful-p= ce we had to make delegation explicit, because the PCE controls the timing = of LSP setups/teardowns. So, when a PCC is ready to accept PCE's path compu= tations and LSP setups, it *explicitly* delegates its LSPs to the PCE. Note that the PCC still owns all its LSPs, = and can withdraw the LSP delegation from a PCE at any time. If a PCC decide= s not to use LSP path/parameters computed by a PCE - it can still do it, ju= st like in the above cases. It simply revokes the LSP delegation from the PCE and does whatever it wants with th= e LSP. However, since it is a stateful PCC, it still MUST tell the PCE what= it has done (sending a PCReport for the LSP).

> (Of course the scope ca= n be widened in future, so let's try to stick to current RFC 4655)

As outlined above, IMO draft= -ietf-pce-stateful-pce is compliant with RFC4655.

Thanks,

Jan

____________________________= ___________________

Pce mailing list<= /span>

Pce@ietf.org

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

--_000_F82A4B6D50F9464B8EBA55651F541CF82D6874E1SZXEML552MBSchi_-- From IBryskin@advaoptical.com Fri Nov 9 06:28:45 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3D21F84A9 for ; Fri, 9 Nov 2012 06:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SPEC_REPLICA_OBFU=1.812] 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 HEiZPTfRhFnr for ; Fri, 9 Nov 2012 06:28:44 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0D02821F8480 for ; Fri, 9 Nov 2012 06:28:43 -0800 (PST) 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 qA9ESclg026466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 15:28:38 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.99.0; Fri, 9 Nov 2012 15:28:38 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0083.000; Fri, 9 Nov 2012 09:28:35 -0500 From: Igor Bryskin To: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= , Julien Meuric Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: Ac29M0Ug4djLg+GXRUWVnAOlC+tbMAA8FkGAAAGpR4AAFrn8wA== Date: Fri, 9 Nov 2012 14:28:34 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> In-Reply-To: <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-09_03:2012-11-08, 2012-11-09, 1970-01-01 signatures=0 Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:28:45 -0000 I completely agree with Oscar. The statefull PCE as defined in RFC 4655 is clearly different from stateful= l PCE as defined in Ed's documents. The cleanest way to think about the lat= ter IMO is a combination of stateless PCE and a network controller, which i= s a very reasonable combination, but is hardly something to be discussed in= PCE working group unless it does not go beyond purely path computation iss= ues. Igor -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Oscar= Gonz=E1lez de Dios Sent: Thursday, November 08, 2012 5:28 PM To: Julien Meuric Cc: pce@ietf.org Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and= opinion about stateful PCE Hi Julien Thanks for the reply. As you said, there where several parts of the= message. I will now limit to cover the discussion of the scope of LSP dele= gation and LSP incitation procedures in the charter. For the rest, I will r= eply in separate mails, in private if you want, in sake of advancing the di= scussions, and my apologies if my words have been misunderstood or sounded = harsh. Comments inline "Then, concerning our current scope, you certainly should have a fresh look= at RFC 4655. E.g., section 6.12: "It may be that the PCC-PCE communications (see Section 6.6) can be usefull= y extended beyond a simple request/response interaction.[...] Additionally,= the protocol could be used to collect and report information in support of= a stateful PCE." We are not machines, but as chairs, we consider that the original draft-cra= bbe-pce-stateful-pce, which was adopted by the WG, was consistent with this= statement (which, since included in an RFC, passed IESG review)." [Oscar]: The state synchronization functions, aimed at (citing literally) = provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE ar= e consistent with this statement, they are beyond simple request/response i= nteractions and collect and report information in support of a stateful PCE= . Thus, this function is perfectly OK with RFC 4555. However, I see that the LSP delegation function goes beyond reporting infor= mation to support a stateful PCE. It instructs the PCE to take control of t= he LSP, and, during the life-time of the LSP, citing literally "the PCC gra= nts to a PCE the right to update LSP attributes on one or more LSPs; the PC= E becomes the authoritative source of the LSP's attributes as long as the d= elegation is in effect". Thus, delegation function clearly is not used to p= rovide information to support later path computation. So... unless I have m= istaken the read of RFC 4655, it is explicitly mentioned that the PCE archi= tecture is aimed at solving the problem of path computation. I may have jum= ped over some paragraph where it says that the role of a Path Computation E= lement (stateful o not stateful) is to take care of the control of an LSP..= . but I honestly cannot find such statement anywhere. So... could you give = me some arguments why the delegation of control is in scope of current RFC = 4655? (Of course the scope can be widened in future, so let's try to stick = to current RFC 4655) Best Regards, =D3scar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From jmedved@cisco.com Fri Nov 9 08:27:39 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760A821F85A9 for ; Fri, 9 Nov 2012 08:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.845 X-Spam-Level: X-Spam-Status: No, score=-8.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 nI0dQw40AXoO for ; Fri, 9 Nov 2012 08:27:38 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 560B221F846A for ; Fri, 9 Nov 2012 08:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9333; q=dns/txt; s=iport; t=1352478451; x=1353688051; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MySP6n9Q2XOqSPYsxqNKgM6+B5AftHR2NYgFZh6AFuc=; b=hTsJpQL1lefAH9piwwH4DRVUJnmKivGXSM4yDwpWSXWmB3AH8BjfMMrJ hKeMJDgvZ41BVcS1EWlr5h4eBLV5XVUasJrjB0YLItavb63H54+A+h6Te TEpFk8R8UsWnnA2IN7bS78eDJv1cZdfEd9SkOj4KJs4oqxIz5PYwMN+mD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMMtnVCtJXG+/2dsb2JhbABEgkmDULw1c4EIgh4BAQEDARIBXwcFCwIBCCIiAgIwJQIEDg0ah2IGnViNIQiSb4wUG4UYNmEDpFOBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140615230" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 09 Nov 2012 16:27:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA9GRUMG005289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 16:27:30 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 10:27:30 -0600 From: "Jan Medved (jmedved)" To: Fatai Zhang Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: AQHNvfm+UUvGR5C2qEyyx5swx2GPe5fg6VaAgAAtpACAAHfbgIAAiAQA Date: Fri, 9 Nov 2012 16:27:29 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:

>The delegation of LSP control to a PCE is *implici= t* in RFC4655. When a PCC sends a PCReq message to a PCE requesting path co= mputation (and parameter setting) for an LSP, it effectively

> delegates control over that LSP to the PCE. The d= elegation is valid for one request (and one path computation) only.

[Fatai] I don't th= ink that RFC4655 can support delegation of LSP *control* (even implicitly).= A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated = to the PCE.

By requesting a path comp= utation from a PCE, the PCC gives the PCE authority to determine the ERO, L= SP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is th= e entity that determines these parameters - would you agree?

Now, whether we use = "control", "authority", "power", "mandat= e", whatever - that does not change the fact that the PCC asks the = PCC to determine what the LSP parameters are, and the PCE determines what the LSP parame= ters are. That's what we call delegation - the PCC "delegates" th= e computation of LSP path and determination of LSP parameters to the PCE.

My email states a li= ttle later: "the PCC may or may not use the LSP path/parameters that it got from the= PCE". We all agree that the PCC has the ultimate control over the LSP - it may take the directions from the PCE, it may not= .

draft-ietf-pce-stateful-pce does n= ot change any of this. The PCC gives the PCE the control/authority/mandate/= power to determine the LSP's parameter. But, rather than doing this implicitly by requesting the PCE to determine those p= arameters (in a PCReq message), it does it explicitly. Delegation does not change the paradigm set by RFC4655 and RFC5440 - but i= n addition to LSP parameters, it allows the PCE to determine the timing of = the LSP setup.

If you don't like the term "d= elegation", please suggest another one. I don't particularly care what= we call the mechanism.

Thanks,

Jan

--_000_ACC8AB2D98C05F4E9FBDA092017D97FC1509C0ADxmbalnx10ciscoc_-- From robert.varga@pantheon.sk Fri Nov 9 08:43:31 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FCA21F8B19 for ; Fri, 9 Nov 2012 08:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 NhEUF+xrsxIb for ; Fri, 9 Nov 2012 08:43:30 -0800 (PST) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2A321F8B17 for ; Fri, 9 Nov 2012 08:43:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 1206422232 for ; Fri, 9 Nov 2012 17:43:27 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=softfail (invalid, public key: unsupported version) header.i=@pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+L5ze2WeZyc for ; Fri, 9 Nov 2012 17:43:26 +0100 (CET) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Fri, 9 Nov 2012 17:43:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id E89FFC945 for ; Fri, 9 Nov 2012 17:43:25 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZaH7AyxZ8M0o for ; Fri, 9 Nov 2012 17:43:25 +0100 (CET) Received: from [130.129.80.93] (dhcp-505d.meeting.ietf.org [130.129.80.93]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 0D39D1E1D for ; Fri, 9 Nov 2012 17:43:24 +0100 (CET) X-DKIM: OpenDKIM Filter v2.6.0 cipisek.dmz.pantheon.local 0D39D1E1D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1352479405; bh=IfqhEbS5UV+fZK2sa9ctYIWA3+uX3oeS/ik2TbaOo84=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=AoH9Y35aZOkV1SnmBtXDa+eDS4aU5g+KqsRaUuQKQ35KErbive1ZTcnLEOKRcIw1B cw+yiaQmBU6AyCgqVG8xQ/tta48SPXAtEi34pfSXU04HaU4v+Yxs/YbjWwHEliwleJ ifYMkAWjvCzRXJSH42XC2B+l2JdF3RHHLTF7It0g= Message-ID: <509D32AA.2040802@pantheon.sk> Date: Fri, 09 Nov 2012 17:43:22 +0100 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pce@ietf.org References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

In-Reply-To: Content-Type: multipart/alternative; boundary="------------040501010802070303030403" Subject: Re: [Pce] =?utf-8?b?562U5aSNOiAgUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBD?= =?utf-8?q?E=2C_relation_to_WG_charter_and_opinion_about_stateful_PCE?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 16:43:31 -0000 This is a multi-part message in MIME format. --------------040501010802070303030403 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/09/2012 09:20 AM, Fatai Zhang wrote: > > Hi Jan, > Hi Fatai, > >The PCE is not limited to path computation only. The PCE can set other LSP > parameters as well: RFC5440 defines objects for bandwidth, setup & > hold priorities, the local protection flag, etc. More LSP parameters > have been added in subsequent RFCs and drafts. > > [Fatai] I have to indicate that PCE cannot *set* other LSP parameters. > The parameters (eg., bandwidth, priorities, etc) you mentioned are > only used for *path computation*. > I agree. The PCE does not set *any* parameters of the LSP. Only PCC can do that PCC. PCE can only provide suggestions and must be fully prepared to have them rejected. I am not aware of any restriction on what information a PCE is allowed to suggest to be modified, apart from the fact that ERO and BANDWIDTH are explictly included in that set (section 5.1.5 of RFC4657). Bye, Robert --------------040501010802070303030403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 11/09/2012 09:20 AM, Fatai Zhang wrote:

Hi Jan,

Hi Fatai,

=

=C2=A0<= /span>

>The PCE is not limited to path computation only. The PCE can set other LSP parameters as well: RFC5440 defines objects for bandwidth, setup & hold priorities, the local protection flag, etc. More LSP parameters have been added in subsequent RFCs and drafts.

=C2=A0<= /span>

[Fatai] I have to indicate that PCE cannot *set* other LSP parameters. The parameters (eg., bandwidth, priorities, etc) you mentioned are only used for *path computation*.

I agree. The PCE does not set *any* parameters of the LSP. Only PCC can do that PCC. PCE can only provide suggestions and must be fully prepared to have them rejected.

I am not aware of any restriction on what information a PCE is allowed to suggest to be modified, apart from the fact that ERO and BANDWIDTH are explictly included in that set (section 5.1.5 of RFC4657).

Bye,
Robert

--------------040501010802070303030403-- From jmedved@cisco.com Fri Nov 9 09:16:04 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4536721F8779 for ; Fri, 9 Nov 2012 09:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.637 X-Spam-Level: X-Spam-Status: No, score=-8.637 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812] 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 uOM7FoNcQgEd for ; Fri, 9 Nov 2012 09:16:03 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5221F87B1 for ; Fri, 9 Nov 2012 09:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4948; q=dns/txt; s=iport; t=1352481362; x=1353690962; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i8qGmG/Xtz3BSwq1B302ESqfXfIP9xKOD86/t+M5E9g=; b=LYOkoCo08lwmqfY+m5rULsriIvUrP2kYRo7IOgAX6J27vriThL7e7Qq1 mrX5RXb7UT4rkYtSQFZNgj9eN4zP8+6Pyv3mkMbSgFfhWQfWOlotlYWWF EsfrDfubmpoihYz8Q3x4rV8gQgdmAKI3aqNIeii5LqlABO4BmuIJQ+6JQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOA5nVCtJV2b/2dsb2JhbABEw0KBCIIeAQEBAwEBAQEPAVsEBwUHBAIBCA4DAQMBAQsdBycLFAMGCAIEDgUIEQmHYgYLnWegFIwUFYVUYQOIJYokkgqBa4JvgVwIFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="137632448" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 09 Nov 2012 17:16:02 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA9HG2dK026422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 17:16:02 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 11:16:01 -0600 From: "Jan Medved (jmedved)" To: Igor Bryskin Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: AQHNvfm+UUvGR5C2qEyyx5swx2GPe5fg6VaAgAEMSwCAAC7HAA== Date: Fri, 9 Nov 2012 17:16:00 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.165] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--57.808500-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: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:16:04 -0000 Igor, On Nov 9, 2012, at 6:28 AM, Igor Bryskin wrote: > I completely agree with Oscar. >=20 > The statefull PCE as defined in RFC 4655 is clearly different from statef= ull PCE as defined in Ed's documents. No it is not. Please see my emails to Oscar and Faital. > The cleanest way to think about the latter IMO is a combination of statel= ess PCE and a network controller, draft-ietf-pce-stateful-pce does not change the architecture outlined in RF= C4655. It proposes an extension to the PCEP protocol that allows the PCE to= do both spatial *and* temporal LSP optimization. The need to add the timin= g aspect (i.e. the timing of LSP setups) to LSP optimization is amply docum= ented in use cases presented in the draft (and use cases presented in other= drafts as well).=20 draft-ietf-pce-stateful-pce does not change the control of the LSPs - it st= ill remains with the PCC. A network controller would have to be able to dyn= amically add/delete LSPs in order to fit in the model that you described ab= ove. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-s= tateful-pce does not. =20 > which is a very reasonable combination, but is hardly something to be dis= cussed in PCE working group unless it does not go beyond purely path comput= ation issues. >=20 > Igor >=20 Thanks, Jan > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Osc= ar Gonz=E1lez de Dios > Sent: Thursday, November 08, 2012 5:28 PM > To: Julien Meuric > Cc: pce@ietf.org > Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter a= nd opinion about stateful PCE >=20 > Hi Julien >=20 > Thanks for the reply. As you said, there where several parts of th= e message. I will now limit to cover the discussion of the scope of LSP del= egation and LSP incitation procedures in the charter. For the rest, I will = reply in separate mails, in private if you want, in sake of advancing the d= iscussions, and my apologies if my words have been misunderstood or sounded= harsh. Comments inline >=20 > "Then, concerning our current scope, you certainly should have a fresh lo= ok at RFC 4655. E.g., section 6.12: > "It may be that the PCC-PCE communications (see Section 6.6) can be usefu= lly extended beyond a simple request/response interaction.[...] Additionall= y, the protocol could be used to collect and report information in support = of a stateful PCE." > We are not machines, but as chairs, we consider that the original draft-c= rabbe-pce-stateful-pce, which was adopted by the WG, was consistent with th= is statement (which, since included in an RFC, passed IESG review)." >=20 > [Oscar]: The state synchronization functions, aimed at (citing literally)= provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE = are consistent with this statement, they are beyond simple request/response= interactions and collect and report information in support of a stateful P= CE. Thus, this function is perfectly OK with RFC 4555. >=20 > However, I see that the LSP delegation function goes beyond reporting inf= ormation to support a stateful PCE. It instructs the PCE to take control of= the LSP, and, during the life-time of the LSP, citing literally "the PCC g= rants to a PCE the right to update LSP attributes on one or more LSPs; the = PCE becomes the authoritative source of the LSP's attributes as long as the= delegation is in effect". Thus, delegation function clearly is not used to= provide information to support later path computation. So... unless I have= mistaken the read of RFC 4655, it is explicitly mentioned that the PCE arc= hitecture is aimed at solving the problem of path computation. I may have j= umped over some paragraph where it says that the role of a Path Computation= Element (stateful o not stateful) is to take care of the control of an LSP= ... but I honestly cannot find such statement anywhere. So... could you giv= e me some arguments why the delegation of control is in scope of current RF= C 4655? (Of course the scope can be widened in future, so let's try to stic= k to current RFC 4655) >=20 > Best Regards, >=20 > =D3scar >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From edc@google.com Fri Nov 9 11:18:49 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9607921F8676 for ; Fri, 9 Nov 2012 11:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.164 X-Spam-Level: X-Spam-Status: No, score=-101.164 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812, 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 FYT2szzX-C7D for ; Fri, 9 Nov 2012 11:18:48 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 337A521F8665 for ; Fri, 9 Nov 2012 11:18:48 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id hm6so694422wib.13 for ; Fri, 09 Nov 2012 11:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=r+kpfZ85flJQ2t1HGo8o13R3j8AJ9TAUHGc7gS9qEm0=; b=d5UaTHBspGYu0V8R0Qt/+9gCU3Ywz+MUhosj57F69OWFuvnbhrIvfukhaZmdKd+Qdo 7e1+e/WMHurfF5WfVix/3crABdbPD97Qms8308B+WoCr0zH+HZBYmRjqpxOUSLFqQahr 3wTmfWIABszBtbLGyHJ15RRsXzzr5uKzpTIW3yrBlGq+Ss/KTLVQCRpz+Xq8J8JSa2Iz A6c/cuEKvYy3MagGfDxYEiN7GhYJcOZHGKvSFoo+30Z0ygW1P474QJY9aeo78R+qJq/W Asj+afX4r4oJ/iWkoFgH4Hzs5dz5Q6o3momXXsa/J+1rYHpMYXn0GrY37R8qE9hjQo6h NuNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=r+kpfZ85flJQ2t1HGo8o13R3j8AJ9TAUHGc7gS9qEm0=; b=TG76PQm+BLTy1MkYdeLtPM/0SEzdd4cI4pPnmG3nIO+rOnVzSiRY+94JUKL4CrICxl Ab+U5QDd1WF5jhg7EVPetyI1uiX1FUDtCNcBaiIKnCVuajGFvJkdmJnZgPU4JbC/gdhd FiOpjuRV/aiWTClkjuGX00BIkCVlNBI3mjN3awseY9AQPT7lvPVinp9wUu5NXzn0Gl7h XQgzochddFwkpxXF/XunLpWP26q3yvuJa1ldI9YdyP0zdluwnoyBivT4n8Jqo1c+C9Gs S7iM7KsCGlh/0J0igEaaT+njr5K5+xmgibpQA5A++ecWGBaD2mktzrsxPwrYKcFJA5Sc GhbQ== Received: by 10.180.99.97 with SMTP id ep1mr4234002wib.9.1352488727299; Fri, 09 Nov 2012 11:18:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.124.66 with HTTP; Fri, 9 Nov 2012 11:18:06 -0800 (PST) From: Edward Crabbe Date: Fri, 9 Nov 2012 14:18:06 -0500 Message-ID: To: Igor Bryskin Content-Type: multipart/alternative; boundary=f46d04428e762744d004ce14d2d1 X-Gm-Message-State: ALoCoQkZ6SMS4rfpJLubWUMlTwVMj8lrCYMqSeOWRrw6Sm5MfcwUvAvY86A4DfTX7IfJqdQjASiDBwD+FJY8ybh2rO5s42MOLrCN7zB0P/+KCqmWWSFm9BTafIrTNiH+u2fu2EsOf96Sx0hogLGLofz2KF41UjyI7Canzz68SS3wnzEdCLL82jf5xEeKb/Lcufx6DkLZtE80 Cc: "pce@ietf.org" Subject: [Pce] Control vs Computation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:18:49 -0000 --f46d04428e762744d004ce14d2d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Igor et al Can we please separate the discussions, as Oscar made multiple unrelated arguments in the original post? I'm renaming this thread. On Fri, Nov 9, 2012 at 9:28 AM, Igor Bryskin wrot= e: > I completely agree with Oscar. > > The statefull PCE as defined in RFC 4655 is clearly different from > statefull PCE as defined in Ed's documents. The cleanest way to think abo= ut > the latter IMO is a combination of stateless PCE and a network controller= , > which is a very reasonable combination, but is hardly something to be > discussed in PCE working group unless it does not go beyond purely path > computation issues. > > Igor > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Oscar Gonz=E1lez de Dios > Sent: Thursday, November 08, 2012 5:28 PM > To: Julien Meuric > Cc: pce@ietf.org > Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter > and opinion about stateful PCE > > Hi Julien > > Thanks for the reply. As you said, there where several parts of > the message. I will now limit to cover the discussion of the scope of LSP > delegation and LSP incitation procedures in the charter. For the rest, I > will reply in separate mails, in private if you want, in sake of advancin= g > the discussions, and my apologies if my words have been misunderstood or > sounded harsh. Comments inline > > "Then, concerning our current scope, you certainly should have a fresh > look at RFC 4655. E.g., section 6.12: > "It may be that the PCC-PCE communications (see Section 6.6) can be > usefully extended beyond a simple request/response interaction.[...] > Additionally, the protocol could be used to collect and report informatio= n > in support of a stateful PCE." > We are not machines, but as chairs, we consider that the original > draft-crabbe-pce-stateful-pce, which was adopted by the WG, was consisten= t > with this statement (which, since included in an RFC, passed IESG review)= ." > > [Oscar]: The state synchronization functions, aimed at (citing literally) > provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE > are consistent with this statement, they are beyond simple request/respon= se > interactions and collect and report information in support of a stateful > PCE. Thus, this function is perfectly OK with RFC 4555. > > However, I see that the LSP delegation function goes beyond reporting > information to support a stateful PCE. It instructs the PCE to take contr= ol > of the LSP, and, during the life-time of the LSP, citing literally "the P= CC > grants to a PCE the right to update LSP attributes on one or more LSPs; t= he > PCE becomes the authoritative source of the LSP's attributes as long as t= he > delegation is in effect". Thus, delegation function clearly is not used t= o > provide information to support later path computation. So... unless I hav= e > mistaken the read of RFC 4655, it is explicitly mentioned that the PCE > architecture is aimed at solving the problem of path computation. I may > have jumped over some paragraph where it says that the role of a Path > Computation Element (stateful o not stateful) is to take care of the > control of an LSP... but I honestly cannot find such statement anywhere. > So... could you give me some arguments why the delegation of control is i= n > scope of current RFC 4655? (Of course the scope can be widened in future, > so let's try to stick to current RFC 4655) > > Best Regards, > > =D3scar > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el= enlace > situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > --f46d04428e762744d004ce14d2d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Igor e= t al

Can we please separate the discussions, as Oscar ma= de multiple unrelated arguments in the original post? =A0I'm renaming t= his thread.=A0

On Fri, Nov 9, 2012 at 9:28 AM, Igor Bryskin= <IBryskin@advaoptical.com> wrote:

I completely agree with Oscar.

The statefull PCE as defined in RFC 4655 is clearly different from stateful= l PCE as defined in Ed's documents. The cleanest way to think about the= latter IMO is a combination of stateless PCE and a network controller, whi= ch is a very reasonable combination, but is hardly something to be discusse= d in PCE working group unless it does not go beyond purely path computation= issues.

Igor

-----Original Message-----
From: pce-bounces@ietf.org [mai= lto:pce-bounces@ietf.org] On Be= half Of Oscar Gonz=E1lez de Dios
Sent: Thursday, November 08, 2012 5:28 PM
To: Julien Meuric
Cc: pce@ietf.org
Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and= opinion about stateful PCE

Hi Julien

=A0 =A0 =A0 =A0 Thanks for the reply. As you said, there where several part= s of the message. I will now limit to cover the discussion of the scope of = LSP delegation and LSP incitation procedures in the charter. For the rest, = I will reply in separate mails, in private if you want, in sake of advancin= g the discussions, and my apologies if my words have been misunderstood or = sounded harsh. Comments inline

"Then, concerning our current scope, you certainly should have a fresh= look at RFC 4655. E.g., section 6.12:
"It may be that the PCC-PCE communications (see Section 6.6) can be us= efully extended beyond a simple request/response interaction.[...] Addition= ally, the protocol could be used to collect and report information in suppo= rt of a stateful PCE."
We are not machines, but as chairs, we consider that the original draft-cra= bbe-pce-stateful-pce, which was adopted by the WG, was consistent with this= statement (which, since included in an RFC, passed IESG review)."

[Oscar]: The state synchronization functions, aimed at (citing literally) = =A0provide a checkpoint-in-time state replica of a PCC's LSP state in a= PCE are consistent with this statement, they are beyond simple request/res= ponse interactions and collect and report information in support of a state= ful PCE. Thus, this function is perfectly OK with RFC 4555.

However, I see that the LSP delegation function goes beyond reporting infor= mation to support a stateful PCE. It instructs the PCE to take control of t= he LSP, and, during the life-time of the LSP, citing literally "the PC= C grants to a PCE the right to update LSP attributes on one or more LSPs; t= he PCE becomes the authoritative source of the LSP's attributes as long= as the delegation is in effect". Thus, delegation function clearly is= not used to provide information to support later path computation. So... u= nless I have mistaken the read of RFC 4655, it is explicitly mentioned that= the PCE architecture is aimed at solving the problem of path computation. = I may have jumped over some paragraph where it says that the role of a Path= Computation Element (stateful o not stateful) is to take care of the contr= ol of an LSP... but I honestly cannot find such statement anywhere. So... c= ould you give me some arguments why the delegation of control is in scope o= f current RFC 4655? (Of course the scope can be widened in future, so let&#= 39;s try to stick to current RFC 4655)

Best Regards,

=A0 =A0 =A0 =A0 =D3scar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
= http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--f46d04428e762744d004ce14d2d1-- From IBryskin@advaoptical.com Fri Nov 9 11:22:09 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7562F21F86D0 for ; Fri, 9 Nov 2012 11:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] 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 HPHb+qhJYAN3 for ; Fri, 9 Nov 2012 11:22:01 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3721F850A for ; Fri, 9 Nov 2012 11:22:00 -0800 (PST) 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 qA9JLtIh014585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 20:21:55 +0100 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.99.0; Fri, 9 Nov 2012 20:21:55 +0100 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.516.32; Fri, 9 Nov 2012 20:21:54 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0083.000; Fri, 9 Nov 2012 14:21:52 -0500 From: Igor Bryskin To: "Jan Medved (jmedved)" Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: Ac29M0Ug4djLg+GXRUWVnAOlC+tbMAA8FkGAAAGpR4AAFrn8wAAQqEsAAAZIXjA= Date: Fri, 9 Nov 2012 19:21:51 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

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-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-09_03:2012-11-09, 2012-11-09, 1970-01-01 signatures=0 Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:22:09 -0000 Jan, You said: =3D> draft-ietf-pce-stateful-pce does not change the control of the LSPs - = it still remains with the PCC. A network controller would have to be able t= o dynamically add/delete LSPs in order to fit in the model that you describ= ed =20 above. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf= -pce-stateful-pce does not. By this you are acknowledging that statefull pce can do a sub-set of things= that stateless pce - network controller combo is able to do. So what is t= he point to discuss a solution that is worse than existing one? Igor=20 -----Original Message----- From: Jan Medved (jmedved) [mailto:jmedved@cisco.com]=20 Sent: Friday, November 09, 2012 12:16 PM To: Igor Bryskin Cc: Oscar Gonz=E1lez de Dios; Julien Meuric; pce@ietf.org Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and= opinion about stateful PCE Igor, On Nov 9, 2012, at 6:28 AM, Igor Bryskin wrote: > I completely agree with Oscar. >=20 > The statefull PCE as defined in RFC 4655 is clearly different from statef= ull PCE as defined in Ed's documents. No it is not. Please see my emails to Oscar and Faital. > The cleanest way to think about the latter IMO is a combination of statel= ess PCE and a network controller, draft-ietf-pce-stateful-pce does not change the architecture outlined in RF= C4655. It proposes an extension to the PCEP protocol that allows the PCE to= do both spatial *and* temporal LSP optimization. The need to add the timin= g aspect (i.e. the timing of LSP setups) to LSP optimization is amply docum= ented in use cases presented in the draft (and use cases presented in other= drafts as well).=20 draft-ietf-pce-stateful-pce does not change the control of the LSPs - it st= ill remains with the PCC. A network controller would have to be able to dyn= amically add/delete LSPs in order to fit in the model that you described ab= ove. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-s= tateful-pce does not. =20 > which is a very reasonable combination, but is hardly something to be dis= cussed in PCE working group unless it does not go beyond purely path comput= ation issues. >=20 > Igor >=20 Thanks, Jan > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Osc= ar Gonz=E1lez de Dios > Sent: Thursday, November 08, 2012 5:28 PM > To: Julien Meuric > Cc: pce@ietf.org > Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter a= nd opinion about stateful PCE >=20 > Hi Julien >=20 > Thanks for the reply. As you said, there where several parts of th= e message. I will now limit to cover the discussion of the scope of LSP del= egation and LSP incitation procedures in the charter. For the rest, I will = reply in separate mails, in private if you want, in sake of advancing the d= iscussions, and my apologies if my words have been misunderstood or sounded= harsh. Comments inline >=20 > "Then, concerning our current scope, you certainly should have a fresh lo= ok at RFC 4655. E.g., section 6.12: > "It may be that the PCC-PCE communications (see Section 6.6) can be usefu= lly extended beyond a simple request/response interaction.[...] Additionall= y, the protocol could be used to collect and report information in support = of a stateful PCE." > We are not machines, but as chairs, we consider that the original draft-c= rabbe-pce-stateful-pce, which was adopted by the WG, was consistent with th= is statement (which, since included in an RFC, passed IESG review)." >=20 > [Oscar]: The state synchronization functions, aimed at (citing literally)= provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE = are consistent with this statement, they are beyond simple request/response= interactions and collect and report information in support of a stateful P= CE. Thus, this function is perfectly OK with RFC 4555. >=20 > However, I see that the LSP delegation function goes beyond reporting inf= ormation to support a stateful PCE. It instructs the PCE to take control of= the LSP, and, during the life-time of the LSP, citing literally "the PCC g= rants to a PCE the right to update LSP attributes on one or more LSPs; the = PCE becomes the authoritative source of the LSP's attributes as long as the= delegation is in effect". Thus, delegation function clearly is not used to= provide information to support later path computation. So... unless I have= mistaken the read of RFC 4655, it is explicitly mentioned that the PCE arc= hitecture is aimed at solving the problem of path computation. I may have j= umped over some paragraph where it says that the role of a Path Computation= Element (stateful o not stateful) is to take care of the control of an LSP= ... but I honestly cannot find such statement anywhere. So... could you giv= e me some arguments why the delegation of control is in scope of current RF= C 4655? (Of course the scope can be widened in future, so let's try to stic= k to current RFC 4655) >=20 > Best Regards, >=20 > =D3scar >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From IBryskin@advaoptical.com Fri Nov 9 11:55:13 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369DB21F867E for ; Fri, 9 Nov 2012 11:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] 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 MX+iLU5KzdQ7 for ; Fri, 9 Nov 2012 11:55:12 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDD321F85F0 for ; Fri, 9 Nov 2012 11:55:11 -0800 (PST) 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 qA9Jt4TO009385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 20:55:05 +0100 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.99.0; Fri, 9 Nov 2012 20:55:04 +0100 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.516.32; Fri, 9 Nov 2012 20:55:04 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0083.000; Fri, 9 Nov 2012 14:55:02 -0500 From: Igor Bryskin To: "Jan Medved (jmedved)" Thread-Topic: Control vs. computation Thread-Index: Ac2+spzwy7490zYDR6mLUqr3sJDUDg== Date: Fri, 9 Nov 2012 19:55:01 +0000 Message-ID: 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-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-09_03:2012-11-09, 2012-11-09, 1970-01-01 signatures=0 Cc: "pce@ietf.org" Subject: [Pce] Control vs. computation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:55:13 -0000 Ed, Jan and all, CCAMP has developed a mechanism (RFC5493 and RFC 5852), using which a netwo= rk controller can obtain the ownership of LSPs created via control plane. This done, the network controller can use information received from the com= panion stateless PCE to optimize their paths and then return the ownership = back to control plane with the suggestion of their rerouting. Have you considered this option? Igor -----Original Message----- From: Jan Medved (jmedved) [mailto:jmedved@cisco.com]=20 Sent: Friday, November 09, 2012 12:16 PM To: Igor Bryskin Cc: Oscar Gonz=E1lez de Dios; Julien Meuric; pce@ietf.org Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and= opinion about stateful PCE Igor, On Nov 9, 2012, at 6:28 AM, Igor Bryskin wrote: > I completely agree with Oscar. >=20 > The statefull PCE as defined in RFC 4655 is clearly different from statef= ull PCE as defined in Ed's documents. No it is not. Please see my emails to Oscar and Faital. > The cleanest way to think about the latter IMO is a combination of statel= ess PCE and a network controller, draft-ietf-pce-stateful-pce does not change the architecture outlined in RF= C4655. It proposes an extension to the PCEP protocol that allows the PCE to= do both spatial *and* temporal LSP optimization. The need to add the timin= g aspect (i.e. the timing of LSP setups) to LSP optimization is amply docum= ented in use cases presented in the draft (and use cases presented in other= drafts as well).=20 draft-ietf-pce-stateful-pce does not change the control of the LSPs - it st= ill remains with the PCC. A network controller would have to be able to dyn= amically add/delete LSPs in order to fit in the model that you described ab= ove. draft-crabbe-pce-pce-initiated-lsp-00 goes there, but draft-ietf-pce-s= tateful-pce does not. =20 > which is a very reasonable combination, but is hardly something to be dis= cussed in PCE working group unless it does not go beyond purely path comput= ation issues. >=20 > Igor >=20 Thanks, Jan > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Osc= ar Gonz=E1lez de Dios > Sent: Thursday, November 08, 2012 5:28 PM > To: Julien Meuric > Cc: pce@ietf.org > Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter a= nd opinion about stateful PCE >=20 > Hi Julien >=20 > Thanks for the reply. As you said, there where several parts of th= e message. I will now limit to cover the discussion of the scope of LSP del= egation and LSP incitation procedures in the charter. For the rest, I will = reply in separate mails, in private if you want, in sake of advancing the d= iscussions, and my apologies if my words have been misunderstood or sounded= harsh. Comments inline >=20 > "Then, concerning our current scope, you certainly should have a fresh lo= ok at RFC 4655. E.g., section 6.12: > "It may be that the PCC-PCE communications (see Section 6.6) can be usefu= lly extended beyond a simple request/response interaction.[...] Additionall= y, the protocol could be used to collect and report information in support = of a stateful PCE." > We are not machines, but as chairs, we consider that the original draft-c= rabbe-pce-stateful-pce, which was adopted by the WG, was consistent with th= is statement (which, since included in an RFC, passed IESG review)." >=20 > [Oscar]: The state synchronization functions, aimed at (citing literally)= provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE = are consistent with this statement, they are beyond simple request/response= interactions and collect and report information in support of a stateful P= CE. Thus, this function is perfectly OK with RFC 4555. >=20 > However, I see that the LSP delegation function goes beyond reporting inf= ormation to support a stateful PCE. It instructs the PCE to take control of= the LSP, and, during the life-time of the LSP, citing literally "the PCC g= rants to a PCE the right to update LSP attributes on one or more LSPs; the = PCE becomes the authoritative source of the LSP's attributes as long as the= delegation is in effect". Thus, delegation function clearly is not used to= provide information to support later path computation. So... unless I have= mistaken the read of RFC 4655, it is explicitly mentioned that the PCE arc= hitecture is aimed at solving the problem of path computation. I may have j= umped over some paragraph where it says that the role of a Path Computation= Element (stateful o not stateful) is to take care of the control of an LSP= ... but I honestly cannot find such statement anywhere. So... could you giv= e me some arguments why the delegation of control is in scope of current RF= C 4655? (Of course the scope can be widened in future, so let's try to stic= k to current RFC 4655) >=20 > Best Regards, >=20 > =D3scar >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el e= nlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send and = receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From jmedved@cisco.com Fri Nov 9 14:24:48 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8421F868F for ; Fri, 9 Nov 2012 14:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.722 X-Spam-Level: X-Spam-Status: No, score=-9.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 QDT1cLSWCn0q for ; Fri, 9 Nov 2012 14:24:48 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0D38F21F8682 for ; Fri, 9 Nov 2012 14:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1352499888; x=1353709488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LacJP06F+a8JkW7t8cOoJ6YgGtXbhz27Fm+jFmBILY8=; b=CFWZIxQClKxEC7Tzz523cA1sQ26pmSh6PLWaK/XGsVfbiaF232X7CgXn +/LYl3ymDQBF5YFHk57GPeCoF6gQ7R8Neis/Zl+HIL59jExOYNVrwHPT8 0w1DljHKXDv9dpMrvFUX2qEfDpbfPfdcbhsGeqA9+CJhsFFTWdIReT6E+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAISBnVCtJXHA/2dsb2JhbABEw0CBCIIeAQEBAwESATQrBwULAgEWFBkLMiUCBA4NEweHYgaeBJEbjnOMFIVpYQOIJYokkgqBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140726328" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2012 22:24:47 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA9MOlDi025343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 22:24:47 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 16:24:47 -0600 From: "Jan Medved (jmedved)" To: Igor Bryskin Thread-Topic: Control vs. Computation (was Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE) Thread-Index: AQHNvskGJEUlAARubkGdWJx/47UENw== Date: Fri, 9 Nov 2012 22:24:47 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.85] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF83582EE0BSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] =?gb2312?b?tPC4tDogIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0Us?= =?gb2312?b?IHJlbGF0aW9uIHRvIFdHIGNoYXJ0ZXIgYW5kIG9waW5pb24gYWJvdXQgc3Rh?= =?gb2312?b?dGVmdWwgUENF?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 02:57:07 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF83582EE0BSZXEML552MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmFuLA0KWW91IHNhaWQ6DQo9PkJ5IHJlcXVlc3RpbmcgYSBwYXRoIGNvbXB1dGF0aW9uIGZy b20gYSBQQ0UsIHRoZSBQQ0MgZ2l2ZXMgdGhlIFBDRSBhdXRob3JpdHkgdG8gZGV0ZXJtaW5lIHRo ZSBFUk8sIExTUCBCYW5kd2lkdGgsIHByb3RlY3Rpb24sIExTUCBzZXR1cCBhbmQgaG9sZCBwcmlv cml0aWVzLCBldGMuIFRoZSBQQ0UgaXMgdGhlIGVudGl0eSB0aGF0IGRldGVybWluZXMgdGhlc2Ug cGFyYW1ldGVycyAtIHdvdWxkIHlvdSBhZ3JlZT8NCg0KW0ZhdGFpXSBTb3JyeSwgSSBkb26hr3Qg YWdyZWUuIFRoZSBwYXJhbWV0ZXJzIChMU1AgYmFuZHdpZHRoLCBwcm90ZWN0aW9uLCBldGMpIGFy ZSB0aGUgY29uc3RyYWludHMgc2VudCBmcm9tIFBDQyB0byBQQ0UgZm9yICpwYXRoIGNvbXB1dGF0 aW9uKi4gRm9yIGV4YW1wbGUsIGEgUENDIHNlbmRzIGEgUENSZXEgdG8gcmVxdWVzdCBhIExTUCB3 aXRoIGJhbmR3aWR0aCAxR3BicywgYW5kIHRoZW4gdGhlIFBDRSBNVVNUIG5vdCByZXR1cm4gYSBw YXRoIHdpdGggZS5nLCAxMDBNYnBzLCBpZS4sIHRoZSBQQ0UgKmNhbm5vdCBkZXRlcm1pbmUqIHRo ZXNlIHBhcmFtZXRlcnMuICBUaGUgRVJPIGlzIHRoZSBwYXRoIGluZm9ybWF0aW9uIChwYXRoIGxp c3QpIHRoYXQgUENFIHJldHVybnMgdG8gUENDIGFmdGVyIHBhdGggY29tcHV0YXRpb24uDQoNCklm IHlvdSB3YW50IHRvIGludHJvZHVjZSAqZGVsZWdhdGlvbiogZnVuY3Rpb24gKHdoYXRldmVyIHdl IGNhbGwgaXQpLCB0aGUgZGVsZWdhdGlvbiBkZWZpbmludGlvbiBzaG91bGQgYmUgZGVmaW5lZCBj bGVhcmx5LiBBbmQgdGhlbiB0aGUgV0cgd2lsbC9jYW4gZGlzY3VzcyBtb3JlIHdoZXRoZXIgdGhp cyChsGRlbGVnYXRpb26hsSBpcyBuZWVkZWQgb3Igbm90IChhbmQgd2hldGhlciB0aGlzIKGwZGVs ZWdhdGlvbqGxIGlzIGluIHRoZSBzY29wZSBvZiB0aGUgZXhpc3RpbmcgY2hhcnRlcikuDQoNCg0K QmVzdCBSZWdhcmRzDQoNCkZhdGFpDQoNCreivP7IyzogSmFuIE1lZHZlZCAoam1lZHZlZCkgW21h aWx0bzpqbWVkdmVkQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDEyxOoxMdTCMTDI1SAwOjI3DQrK 1bz+yMs6IEZhdGFpIFpoYW5nDQqzrcvNOiBPc2NhciBHb256qKJsZXogZGUgRGlvczsgcGNlQGll dGYub3JnDQrW98ziOiBSZTogW1BjZV0gUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBDRSwgcmVs YXRpb24gdG8gV0cgY2hhcnRlciBhbmQgb3BpbmlvbiBhYm91dCBzdGF0ZWZ1bCBQQ0UNCg0KRmFp dGFsLA0KDQpPbiBOb3YgOSwgMjAxMiwgYXQgMTI6MjAgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0K DQoNCj5UaGUgZGVsZWdhdGlvbiBvZiBMU1AgY29udHJvbCB0byBhIFBDRSBpcyAqaW1wbGljaXQq IGluIFJGQzQ2NTUuIFdoZW4gYSBQQ0Mgc2VuZHMgYSBQQ1JlcSBtZXNzYWdlIHRvIGEgUENFIHJl cXVlc3RpbmcgcGF0aCBjb21wdXRhdGlvbiAoYW5kIHBhcmFtZXRlciBzZXR0aW5nKSBmb3IgYW4g TFNQLCBpdCBlZmZlY3RpdmVseQ0KPiBkZWxlZ2F0ZXMgY29udHJvbCBvdmVyIHRoYXQgTFNQIHRv IHRoZSBQQ0UuIFRoZSBkZWxlZ2F0aW9uIGlzIHZhbGlkIGZvciBvbmUgcmVxdWVzdCAoYW5kIG9u ZSBwYXRoIGNvbXB1dGF0aW9uKSBvbmx5Lg0KDQpbRmF0YWldIEkgZG9uJ3QgdGhpbmsgdGhhdCBS RkM0NjU1IGNhbiBzdXBwb3J0IGRlbGVnYXRpb24gb2YgTFNQICpjb250cm9sKiAoZXZlbiBpbXBs aWNpdGx5KS4gQSBQQ0Mgc2VuZHMgYSBQQ1JlcSB0byBhIFBDRSwgaXQgZG9lcyBub3QgbWVhbiB0 aGF0IHRoaXMgTFNQIGlzIGRlbGVnYXRlZCB0byB0aGUgUENFLg0KDQpCeSByZXF1ZXN0aW5nIGEg cGF0aCBjb21wdXRhdGlvbiBmcm9tIGEgUENFLCB0aGUgUENDIGdpdmVzIHRoZSBQQ0UgYXV0aG9y aXR5IHRvIGRldGVybWluZSB0aGUgRVJPLCBMU1AgQmFuZHdpZHRoLCBwcm90ZWN0aW9uLCBMU1Ag c2V0dXAgYW5kIGhvbGQgcHJpb3JpdGllcywgZXRjLiBUaGUgUENFIGlzIHRoZSBlbnRpdHkgdGhh dCBkZXRlcm1pbmVzIHRoZXNlIHBhcmFtZXRlcnMgLSB3b3VsZCB5b3UgYWdyZWU/DQoNCk5vdywg d2hldGhlciB3ZSB1c2UgImNvbnRyb2wiLCAiYXV0aG9yaXR5IiwgInBvd2VyIiwgIm1hbmRhdGUi LCB3aGF0ZXZlciAtIHRoYXQgZG9lcyBub3QgY2hhbmdlIHRoZSBmYWN0IHRoYXQgdGhlIFBDQyBh c2tzIHRoZSBQQ0MgdG8gZGV0ZXJtaW5lIHdoYXQgdGhlIExTUCBwYXJhbWV0ZXJzIGFyZSwgYW5k IHRoZSBQQ0UgZGV0ZXJtaW5lcyB3aGF0IHRoZSBMU1AgcGFyYW1ldGVycyBhcmUuIFRoYXQncyB3 aGF0IHdlIGNhbGwgZGVsZWdhdGlvbiAtIHRoZSBQQ0MgImRlbGVnYXRlcyIgdGhlIGNvbXB1dGF0 aW9uIG9mIExTUCBwYXRoIGFuZCBkZXRlcm1pbmF0aW9uIG9mIExTUCBwYXJhbWV0ZXJzIHRvIHRo ZSBQQ0UuDQoNCk15IGVtYWlsIHN0YXRlcyBhIGxpdHRsZSBsYXRlcjogInRoZSBQQ0MgbWF5IG9y IG1heSBub3QgdXNlIHRoZSBMU1AgcGF0aC9wYXJhbWV0ZXJzIHRoYXQgaXQgZ290IGZyb20gdGhl IFBDRSIuIFdlIGFsbCBhZ3JlZSB0aGF0IHRoZSBQQ0MgaGFzIHRoZSB1bHRpbWF0ZSBjb250cm9s IG92ZXIgdGhlIExTUCAtIGl0IG1heSB0YWtlIHRoZSBkaXJlY3Rpb25zIGZyb20gdGhlIFBDRSwg aXQgbWF5IG5vdC4NCg0KZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlIGRvZXMgbm90IGNoYW5n ZSBhbnkgb2YgdGhpcy4gVGhlIFBDQyBnaXZlcyB0aGUgUENFIHRoZSBjb250cm9sL2F1dGhvcml0 eS9tYW5kYXRlL3Bvd2VyIHRvIGRldGVybWluZSB0aGUgTFNQJ3MgcGFyYW1ldGVyLiBCdXQsIHJh dGhlciB0aGFuIGRvaW5nIHRoaXMgaW1wbGljaXRseSBieSByZXF1ZXN0aW5nIHRoZSBQQ0UgdG8g ZGV0ZXJtaW5lIHRob3NlIHBhcmFtZXRlcnMgKGluIGEgUENSZXEgbWVzc2FnZSksIGl0IGRvZXMg aXQgZXhwbGljaXRseS4gRGVsZWdhdGlvbiBkb2VzIG5vdCBjaGFuZ2UgdGhlIHBhcmFkaWdtIHNl dCBieSBSRkM0NjU1IGFuZCBSRkM1NDQwIC0gYnV0IGluIGFkZGl0aW9uIHRvIExTUCBwYXJhbWV0 ZXJzLCBpdCBhbGxvd3MgdGhlIFBDRSB0byBkZXRlcm1pbmUgdGhlIHRpbWluZyBvZiB0aGUgTFNQ IHNldHVwLg0KDQpJZiB5b3UgZG9uJ3QgbGlrZSB0aGUgdGVybSAiZGVsZWdhdGlvbiIsIHBsZWFz ZSBzdWdnZXN0IGFub3RoZXIgb25lLiBJIGRvbid0IHBhcnRpY3VsYXJseSBjYXJlIHdoYXQgd2Ug Y2FsbCB0aGUgbWVjaGFuaXNtLg0KDQoNCg0KVGhhbmtzLA0KSmFuDQoNCg0K --_000_F82A4B6D50F9464B8EBA55651F541CF83582EE0BSZXEML552MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jan,

You said:<= o:p>

=3D>By requesting a path computation f= rom a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwi= dth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

= ;

[Fatai] So= rry, I don=A1=AFt agree. The parameters (LSP bandwidth, protection, etc) ar= e the constraints sent from PCC to PCE for *path computation*. For example, a PCC sends a PCReq to request a LSP w= ith bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the= PCE *cannot determine* these parameters. The ERO is the path = information (path list) that PCE returns to PCC after path computation.

If you want to introduce *<= b>delegation* function (whatever we call it), the delegation definintion should be defined clearly. And then the WG will/can discuss mo= re whether this =A1=B0delegation=A1=B1 is needed or not (and whether this = =A1=B0delegation=A1=B1 is in the scope of the existing charter).

Best Regards

Fatai

= ;

=B7=A2=BC=FE=C8= =CB: Jan Medved (jmedved) [mailto:jmedved@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C210=C8=D5 = 0:27
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2lez de Dios; pce@ietf.org
=D6=F7=CC=E2: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinio= n about stateful PCE

Faital,

On Nov 9, 2012, at 12:20 AM, Fa= tai Zhang wrote:

>The delegation of LS= P control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq messa= ge to a PCE requesting path computation (and parameter setting) for an LSP, it effectively

> delegates control o= ver that LSP to the PCE. The delegation is valid for one request (and one p= ath computation) only.

[Fatai] I = don't think that RFC4655 can support delegation of LSP *control* (even impl= icitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE.<= /o:p>

By requesting a path computation from a P= CE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, pr= otection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

Now, whether we use "control", = "authority", "power", "mandate", whatever - t= hat does not change the fact that the= PCC asks the PCC to determine what the LSP parameters are, and <= /span>the PCE determines what t= he LSP parameters are. That's what we call delegation - the PCC "deleg= ates" the computation of LSP path and determination of LSP parameters to the PCE= .

My email states a little later: "the PCC may= or may not use the LSP path/parameters that it got from the PCE". We all agree that = the PCC has the ultimate control over the LSP - it may take the directions = from the PCE, it may not.

draft-ietf-pce-stateful-pce does not change any of this. The PCC gi= ves the PCE the control/authority/mandate/power to determine the LSP's parameter. But, rather than doing this implicitly by requesting = the PCE to determine those parameters (in a PCReq message), it does it expl= icitly. Delegation does not change the paradigm set by RFC4655 and RFC5440 = - but in addition to LSP parameters, it allows the PCE to determine the timing of the LSP setup.<= span lang=3D"EN-US">

If you don't like the term "delegation", please suggest a= nother one. I don't particularly care what we call the mechanism.

Thanks,

Jan

--_000_F82A4B6D50F9464B8EBA55651F541CF83582EE0BSZXEML552MBXchi_-- From edc@google.com Sun Nov 11 19:59:20 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43C121F84A0 for ; Sun, 11 Nov 2012 19:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.122 X-Spam-Level: X-Spam-Status: No, score=-97.122 tagged_above=-999 required=5 tests=[AWL=-4.042, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, 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 yFaOIOP-o6se for ; Sun, 11 Nov 2012 19:59:17 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7039621F841E for ; Sun, 11 Nov 2012 19:59:17 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so1300793qaa.10 for ; Sun, 11 Nov 2012 19:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ENIUy+T1yuQib6H2F2nYPwXpAoaOkKvBCtkFCL29YDc=; b=nPKBmU1b0nTVZOp5S6i+eULyvd28s0E6ikFrj02QVbdZBQ2zU1d7UqS/D3xwFvoU2T M0f7RivdE57tUpBBZXepqTAKCZCYYPdOYehYtAa0QoIpVeB5bqo3j9+Wkpij0txG1jkB ythKMyweABxiyu0UJ3cYoLYl4MQWAz44Gx8Mz0aTcVQcggkYUggnA8u28M/qXlno71qm 3R4RHSJheLdbO85+pxIYo6DEpOP8/wQw9ALQK1JF7RD0/AauDYzfhI5hsVrlZ9Qh7TGl 2d0m4wpV0kv1rrS+7u6Kj7b+dgl7zD5TyVWGyL5Cl1EMeilO4+6o8fRCui65L9MMLICy HdUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ENIUy+T1yuQib6H2F2nYPwXpAoaOkKvBCtkFCL29YDc=; b=i4gyLBxo5I6AaSuSwjvmN1lrst6Np59N9J3FNPAKALlkcB1Z+0g271MjMulM4MfEBw jXW+KJ+4mC/wDn6wLrm9GlYaLS8Lg2m18P+HgwKSkHlIk93oc617u6s1cFPa4n5shyXL 7GJOCIzZWgFglIxXL1mH9lbYzHvr9iS1g57iBQ4ialXhf6FcN0HhmE322YFuEEFZzN32 TNEypQ7YvXF/LrR8/XIwvCacHwc1XrxLXDhkucdqKUdceh3JYG9jwvFa8ozkriNxcqaI J31to253lp4W37wGw90mTOO+sqDMbeLHlnOtONJlfdi6S1mdkqWbXCDXYxSz76pz8raW /xwA== Received: by 10.224.185.212 with SMTP id cp20mr21212399qab.2.1352692756778; Sun, 11 Nov 2012 19:59:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.75.41 with HTTP; Sun, 11 Nov 2012 19:58:36 -0800 (PST) In-Reply-To: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

From: Edward Crabbe Date: Sun, 11 Nov 2012 19:58:36 -0800 Message-ID: To: Fatai Zhang Content-Type: multipart/alternative; boundary=20cf30334fc5420f8f04ce4453a2 X-Gm-Message-State: ALoCoQmB8BDz50d4SMrm2covOlMzH8OJ6lhN2Tmfjo3t55hDySCj1y2lf2X1VbuDb7xf4sCFQkJia5VpBxui9P+pS6kwelAiXgHDm84thnWcz5JsqZ/Re7YeWiAxFgSFaJkv7yWomc3TQ5+Dn93mtSluUj7vyixejyirF9fiFtuWVfKG1V24Qom1D9jCW/yqINIMU3cHX1FO Cc: "pce@ietf.org" Subject: Re: [Pce] =?gb2312?b?tPC4tDogUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBDRSwg?= =?gb2312?b?cmVsYXRpb24gdG8gV0cgY2hhcnRlciBhbmQgb3BpbmlvbiBhYm91?= =?gb2312?b?dCBzdGF0ZWZ1bCBQQ0U=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 03:59:21 -0000 --20cf30334fc5420f8f04ce4453a2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable We currently appear to be involved in some sort of pre-fiat working group process debate. Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason. At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/ I hope that's not the case. Obviously the working group can have any technical discussion it wants, to within the bounds of reason and the chair's limits of tolerence. ;) So let's do that, and try to make our time together here productive. ^_^ w/r/t the specific comments: Yes, we already have introduced a delegation function and have had since the first rev of the draft. It is, IMO, defined clearly in the draft-crabbe-pce-stateful-pce-02. You should read it. If you don't think the definition is clear, then we should discuss that so we can improve the text. I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang wrote: > Hi Jan,**** > > You said:**** > > =3D>By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree? **** > > ** ** > > [Fatai] Sorry, I don=A1=AFt agree. The parameters (LSP bandwidth, protect= ion, > etc) are the constraints sent from PCC to PCE for **path computation**. > For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, > and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE *= *cannot > determine** these parameters. The ERO is the path information (path > list) that PCE returns to PCC after path computation. **** > > ** ** > > If you want to introduce **delegation** function (whatever we call it), > the delegation definintion should be defined clearly. And then the WG > will/can discuss more whether this =A1=B0delegation=A1=B1 is needed or no= t (and > whether this =A1=B0delegation=A1=B1 is in the scope of the existing chart= er). **** > > ** ** > > ** ** > > Best Regards**** > > ** ** > > Fatai**** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* Jan Medved (jmedved) [mailto:jmedved@cisco.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2012=C4=EA11=D4=C210=C8=D5 0:27 > *=CA=D5=BC=FE=C8=CB:* Fatai Zhang > *=B3=AD=CB=CD:* Oscar Gonz=A8=A2lez de Dios; pce@ietf.org > *=D6=F7=CC=E2:* Re: [Pce] Questions about stateful PCE, relation to WG ch= arter and > opinion about stateful PCE**** > > ** ** > > Faital, **** > > ** ** > > On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:**** > > > > **** > > >The delegation of LSP control to a PCE is *implicit* in RFC4655. When a > PCC sends a PCReq message to a PCE requesting path computation (and > parameter setting) for an LSP, it effectively**** > > > delegates control over that LSP to the PCE. The delegation is valid for > one request (and one path computation) only.**** > > **** > > [Fatai] I don't think that RFC4655 can support delegation of LSP *control= * > (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that th= is > LSP is delegated to the PCE.**** > > ** ** > > By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree? **** > > ** ** > > Now, whether we use "control", "authority", "power", "mandate", whatever = - > that does not change the fact that the PCC asks the PCC to determine what > the LSP parameters are, and the PCE determines what the LSP parameters > are. That's what we call delegation - the PCC "delegates" the computation > of LSP path and determination of LSP parameters to the PCE.**** > > ** ** > > My email states a little later: "the PCC may or may not use the LSP > path/parameters that it got from the PCE". We all agree that the PCC has > the ultimate control over the LSP - it may take the directions from the > PCE, it may not. **** > > ** ** > > draft-ietf-pce-stateful-pce does not change any of this. The PCC gives th= e > PCE the control/authority/mandate/power to determine the LSP's parameter. > But, rather than doing this implicitly by requesting the PCE to determine > those parameters (in a PCReq message), it does it explicitly. Delegation > does not change the paradigm set by RFC4655 and RFC5440 - but in addition > to LSP parameters, it allows the PCE to determine the timing of the LSP > setup.**** > > ** ** > > If you don't like the term "delegation", please suggest another one. I > don't particularly care what we call the mechanism. **** > > ** ** > > ** ** > > ** ** > > Thanks,**** > > Jan**** > > ** ** > > ** ** > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --20cf30334fc5420f8f04ce4453a2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

We currently= appear to be involved in some sort of pre-fiat working group process debat= e. Unfortunately, I think you're injecting a particularly onerous= and unnecessary sort of wg bureaucracy here, and for n= o discernible reason. At this point, given the lack of any substantiv= e technical argument, I have to say that I actually feel that you're be= ing a bit obstructionist. :-/ I hope that's not the case.

Obviously the working group can have any technical discussio= n it wants, to within the bounds of reason and the chair's limits of to= lerence. ;) So let's do that, and try to make our time toge= ther here productive. ^_^

w/r/t the specific comments:

Yes, we already have introduced a delegation function and ha= ve had since the first rev of the draft. It is, IMO, defined cl= early in the draft-crabbe-pce-stateful-pce-02. You should read it. &n= bsp;If you don't think the definition is clear, then we should discuss = that so we can improve the text.

I continue to maintain that the main differences betwee= n receipt of computation results between 5440 and active PCEP as defined in= draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. I= f you have a good reason for thinking that this is not the case, or have ot= her technical issues with the delegation model, then please, by all means..= .

On Sun, Nov 11, 2012 at = 6:56 PM, Fatai Zhang <zhangfatai@huawei.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Hi Jan,=

You said:<= u>

&nb= sp;

[Fatai] So= rry, I don’t agree. The parameters (LSP bandwidth, protection, etc) a= re the constraints sent from PCC to PCE for *path computation*. For example, a PCC sends a PCReq to request a LSP w= ith bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the= PCE *cannot determine* these parameters. The ERO is the path = information (path list) that PCE returns to PCC after path computation.

If you want to introduce *<= b>delegation* function (whatever we call it), the delegation definintion should be defined clearly. And then the WG will/can discuss mo= re whether this “delegation” is needed or not (and whether this= “delegation” is in the scope of the existing charter).

Best Regards<= /span>

Fatai<= /p>

&nb= sp;

=D6=F7=CC=E2: Re: [Pce] Questions about stateful PCE, relation to WG ch= arter and opinion about stateful PCE

Faital,

On Nov 9, 2012, at 12:20 AM, Fa= tai Zhang wrote:

>The delegation of LS= P control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq messa= ge to a PCE requesting path computation (and parameter setting) for an LSP, it effectively

> delegates control o= ver that LSP to the PCE. The delegation is valid for one request (and one p= ath computation) only.

[Fatai] I = don't think that RFC4655 can support delegation of LSP *control* (even = implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE.

Now, whether we use "control", = "authority", "power", "mandate", whatever - t= hat does not change the fact that the PCC asks the PCC to determ= ine what the LSP parameters are, and <= /span>the PCE determines what the LSP parameters are. That= 's what we call delegation - the PCC "delegates" the computation of LSP path and determination of LSP parameters to the PCE= .

My email states a little later: "the PCC may or may not use the LSP path/parameters that it got from the PCE". We all agree that = the PCC has the ultimate control over the LSP - it may take the directions = from the PCE, it may not.

draft-ietf-pce-stat= eful-pce does not change any of this. The PCC gives the PCE the control/aut= hority/mandate/power to determine the LSP's parameter. But, rather than doing this implicitly by request= ing the PCE to determine those parameters (in a PCReq message), it does it = explicitly. Delegation does not change the paradigm set by RFC4655 and RFC5= 440 - but in addition to LSP parameters, it allows the PCE to determine the timing of the LSP setup.<= span lang=3D"EN-US">

If you don't li= ke the term "delegation", please suggest another one. I don't= particularly care what we call the mechanism.

Thanks,

Jan

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

I'= m surprised by your surprise. ^_^

Seriously though= , I don't mean to offend you: I want to have a productive discuss= ion here. Most of the conversation in this thread thus far is about e= ither language, or whether the functionality is within the scope of the cha= rter. I believe one of our chairs has already weighed in on the scope= side, so I guess we're talking about either language or I'm missin= g some technical point you've made regarding mechanism.

W/rt whether the PCE can set parameters: yes, it = clearly can. This is consistent with rfc4655 IMO. As I stated p= reviously:

I continue to maintain that the main differences betwe= en receipt of computation results between 5440 and active PCEP as defined i= n draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you h= ave a good reason for thinking that this is not the case, or have other tec= hnical issues with the delegation model, then please, by all means... = ;

On Sun, Nov 11, 2012 at 8:50 PM, Fatai = Zhang <zhangfatai@huawei.com> wrote:

I am surpr= ised by your tone.

&nb= sp;

I am touch= ing the tech points and trying to clarity why PCE cannot *determine*= those parameters. You can correct me if I am wrong from the tech perspective.

&nb= sp;

If you sti= ll use this kind of tone, sorry, I will ignore your response.=

&nb= sp;

=

=

Best Regards<= /span>

=

Fatai<= /p>
&nb= sp;

=B7=A2=BC=FE=C8= =CB: Edward Crabbe [mailto:edc@google.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C212=C8=D5 = 11:59
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Jan Medved (jmedved); p= ce@ietf.org
=D6=F7=CC=E2: Re: [Pce] =B4=F0=B8=B4: Questions about state= ful PCE, relation to WG charter and opinion about stateful PCE

We currently appear to be = involved in some sort of pre-fiat working group process debate. Unfor= tunately, I think you're injecting a particularly onerous and unne= cessary sort of wg bureaucracy here, and for no discernible reason. At = this point, given the lack of any substantive technical argument, I have to= say that I actually feel that you're being a bit obstructionist. :-/ &= nbsp;I hope that's not the case.

Obviously the working grou= p can have any technical discussion it wants, to within the bounds of reaso= n and the chair's limits of tolerence. ;) So let's do t= hat, and try to make our time together here productive. ^_^

w/r/t the specific comment= s:

Yes, we already have intro= duced a delegation function and have had since the first rev of the draft. = It is, IMO, defined clearly in the draft-crabbe-pce-stateful-pc= e-02. You should read it. If you don't think the definition is c= lear, then we should discuss that so we can improve the text. =

I continue to maintain tha= t the main differences between receipt of computation results between 5440 = and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thin= king that this is not the case, or have other technical issues with the del= egation model, then please, by all means...

On Sun, Nov 11, 2012 at 6:= 56 PM, Fatai Zhang <zhangfatai@huawei.com> wrote:

Hi Jan,

You said:<= /span>

=3D>By requesting a path computation f= rom a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwi= dth, protection, LSP setup and hold priorities, etc. The PCE is the entity that= determines these parameters - would you agree?

[Fatai] So= rry, I don’t agree. The parameters (LSP bandwidth, protection, etc) a= re the constraints sent from PCC to PCE for *path computation*. For exampl= e, a PCC sends a PCReq to<= /span> request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a pat= h with e.g, 100Mbps, ie., the PCE *cannot determine* these parameter= s. The ERO is the path information (path list) that PCE returns to PC= C after path computation.

If you want to introduce *dele= gation* function (whatever we call it), the delegation definintion shou= ld be defined clearly. And then the WG will/can discuss more whether this “delegation” is needed or not (and whether t= his “delegation” is in the scope of the existing charter).

Best Regards

Fatai=

=B7=A2=BC=FE=C8= =CB: Jan Medved (jmedved) [mailto:jmedved@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C210=C8=D5 = 0:27
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2lez de Dios; pce@ietf.org

=D6=F7=CC=E2:= Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE<= u>

Faital,

On Nov 9, 2012, at 12:20 AM, Fa= tai Zhang wrote:

=

>The delegation of LS= P control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq messa= ge to a PCE requesting path computation (and parameter setting) for an LSP, i= t effectively

> delegates control o= ver that LSP to the PCE. The delegation is valid for one request (and one p= ath computation) only.

[Fatai] I = don't think that RFC4655 can support delegation of LSP *control* (even = implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated = to the PCE.

By requesting a path computation from a P= CE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, pr= otection, LSP setup and hold priorities, etc. The PCE is the entity that determines = these parameters - would you agree?

Now, whether we use "control", = "authority", "power", "mandate", whatever - t= hat does not change the fact that the PCC asks the PCC to determine what the LSP parameters are, and the PCE determines what the LSP paramet= ers are. That's what we call delegation - the PCC "delegates"= the computation of LSP path and determination of LSP parameters to the PCE.

My email states a little later: "the PCC may or may not use the LSP path/parameters that it got from the PCE&qu= ot;. We all agree that the PCC has the ultimate control over the LSP - it m= ay take the directions from the PCE, it may not.

draft-ietf-pce-stateful-p= ce does not change any of this. The PCC gives the PCE the control/authority= /mandate/power to determine the LSP's parameter. But, rather than doing this implicit= ly by requesting the PCE to determine those parameters (in a PCReq message)= , it does it explicitly. Delegation does not change the paradigm set by RFC= 4655 and RFC5440 - but in addition to LSP parameters, it allows the PCE to determine the timing of the LSP setup= .

If you don't like the= term "delegation", please suggest another one. I don't parti= cularly care what we call the mechanism.

Thanks,

Jan

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

--bcaec51b1319cb111f04ce454620-- From jmedved@cisco.com Sun Nov 11 21:09:24 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C86621F84D1 for ; Sun, 11 Nov 2012 21:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.516 X-Spam-Level: X-Spam-Status: No, score=-7.516 tagged_above=-999 required=5 tests=[AWL=-1.121, 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 SqVYX2j6acWr for ; Sun, 11 Nov 2012 21:09:22 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7833521F849A for ; Sun, 11 Nov 2012 21:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31135; q=dns/txt; s=iport; t=1352696962; x=1353906562; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SCMnEpwGvAhZFwQwpsbb2dupuMv6QgJ6wiQS82B1tRs=; b=IZ+lese7uK2u4sSe2Nx1sXq4ingCTPFDxXOv9PYy83ZyCbGiTAMupUOo 9sRRdbPLYWCZVa6VIoeZUxlC3srriFE70+7yWvbuYOeYwN5QcTILgu0WU Gu/R4VUCZ1EUMFu9+jbu/WJv/EEX7UvdYnDQoUEWyHaMJQEQwOava3lpM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJyDoFCtJXG9/2dsb2JhbABEgkmDUbxGc4EIgh4BAQEDARIBXwcFCwIBBgISEBYBBgUCAjAUAw4CBA4FCBqHYgabW40hCJFjjBUbhRg2YQOkVIFrgm+BZBce X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141158661" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2012 05:09:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAC59LxY022842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 05:09:21 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Sun, 11 Nov 2012 23:09:21 -0600 From: "Jan Medved (jmedved)" To: Fatai Zhang Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: AQHNvfm+UUvGR5C2qEyyx5swx2GPew== Date: Mon, 12 Nov 2012 05:09:20 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.165] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19354.005 x-tm-as-result: No--61.972900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_ACC8AB2D98C05F4E9FBDA092017D97FC150A1438xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 05:09:24 -0000 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC150A1438xmbalnx10ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RmF0YWksDQoNCk9uIE5vdiAxMSwgMjAxMiwgYXQgNjo1NiBQTSwgRmF0YWkgWmhhbmcgd3JvdGU6 DQoNCkhpIEphbiwNCllvdSBzYWlkOg0KPT5CeSByZXF1ZXN0aW5nIGEgcGF0aCBjb21wdXRhdGlv biBmcm9tIGEgUENFLCB0aGUgUENDIGdpdmVzIHRoZSBQQ0UgYXV0aG9yaXR5IHRvIGRldGVybWlu ZSB0aGUgRVJPLCBMU1AgQmFuZHdpZHRoLCBwcm90ZWN0aW9uLCBMU1Agc2V0dXAgYW5kIGhvbGQg cHJpb3JpdGllcywgZXRjLiBUaGUgUENFIGlzIHRoZSBlbnRpdHkgdGhhdCBkZXRlcm1pbmVzIHRo ZXNlIHBhcmFtZXRlcnMgLSB3b3VsZCB5b3UgYWdyZWU/DQoNCltGYXRhaV0gU29ycnksIEkgZG9u oa90IGFncmVlLiBUaGUgcGFyYW1ldGVycyAoTFNQIGJhbmR3aWR0aCwgcHJvdGVjdGlvbiwgZXRj KSBhcmUgdGhlIGNvbnN0cmFpbnRzIHNlbnQgZnJvbSBQQ0MgdG8gUENFIGZvciAqcGF0aCBjb21w dXRhdGlvbiouDQoNClBsZWFzZSByZS1yZWFkIHJmYzU0NDAuIEEgUENSZXAgKm1heSogY29udGFp biBhbGwgdGhlIGFib3ZlIG9iamVjdHMuIFRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIFJGQzU0NDAg c2F5aW5nIHRoZSBQQ0UgY291bGQgbm90IHNldCB0aGVzZSBwYXJhbWV0ZXJzIGFzIGl0IHNlZXMg Zml0IC0gZXZlbiBjaGFuZ2UgdGhlIEJBTkRXSURUSCBwYXJhbWV0ZXIgc3VnZ2VzdGVkIGJ5IGEg UENDLg0KDQpGb3IgZXhhbXBsZSwgYSBQQ0Mgc2VuZHMgYSBQQ1JlcSB0byByZXF1ZXN0IGEgTFNQ IHdpdGggYmFuZHdpZHRoIDFHcGJzLCBhbmQgdGhlbiB0aGUgUENFIE1VU1Qgbm90IHJldHVybiBh IHBhdGggd2l0aCBlLmcsIDEwME1icHMsIGllLiwgdGhlIFBDRSAqY2Fubm90IGRldGVybWluZSog dGhlc2UgcGFyYW1ldGVycy4gIFRoZSBFUk8gaXMgdGhlIHBhdGggaW5mb3JtYXRpb24gKHBhdGgg bGlzdCkgdGhhdCBQQ0UgcmV0dXJucyB0byBQQ0MgYWZ0ZXIgcGF0aCBjb21wdXRhdGlvbi4NCg0K UGxlYXNlIHJlLXJlYWQgcmZjNTQ0MCAtIEJBTkRXSURUSCBhbmQgYWxsIG90aGVyIExTUCBwYXJh bWV0ZXJzIGFyZSAqb3B0aW9uYWwqIG9uIFBDUmVxLiBBIHVzZSBjYXNlIHdoZXJlIGEgUENDIGRv ZXMgbm90IGluY2x1ZGUgQkFORFdJRFRIIG9uIHRoZSBQQ1JlcSBtZXNzYWdlIGFuZCBsZWF2ZXMg dGhlIGRldGVybWluYXRpb24gb2YgYSBwYXRoJ3MgYmFuZHdpZHRoIHRvIHRoZSBQQ0UgaXMgd2Vs bCB3aXRoaW4gdGhlIHNwZWMuIEFuZCBhcyBJIHNhaWQgYWJvdmUsIGEgUENSZXAgbWF5IG9wdGlv bmFsbHkgY29udGFpbiBiYW5kd2lkdGggYW5kIG90aGVyIExTUCBwYXJhbWV0ZXJzLCBub3QganVz dCB0aGUgRVJPLg0KDQpFdmVuIGlmIHdlIHNheSB0aGF0IHRoZSBvbmx5IHRoaW5nIHRoYXQgdGhl IFBDRSBkb2VzIGlzIHBhdGggY29tcHV0YXRpb24sIHRoZSBQQ0MgKmRlbGVnYXRlcyogcGF0aCBj b21wdXRhdGlvbiB0byB0aGUgUENFLiBUaGF0IG1lYW5zLCBkZWxlZ2F0aW9uIC0gYXMgYSBjb25j ZXB0IC0gaGFzIGJlZW4gYSBwYXJ0IG9mIHRoZSBQQ0UgYXJjaGl0ZWN0dXJlIGZyb20gdGhlIHZl cnkgYmVnaW5uaW5nLiBUaGVyZWZvcmUsIHlvdXIgYXJndW1lbnRzIGFib3ZlIGFib3V0IGJhbmR3 aWR0aCwgZXRjLiBhcmUgbW9vdC4NCg0KSWYgeW91IHdhbnQgdG8gaW50cm9kdWNlICpkZWxlZ2F0 aW9uKiBmdW5jdGlvbiAod2hhdGV2ZXIgd2UgY2FsbCBpdCksIHRoZSBkZWxlZ2F0aW9uIGRlZmlu aW50aW9uIHNob3VsZCBiZSBkZWZpbmVkIGNsZWFybHkuDQoNCldlIGRvbid0IGhhdmUgdG8gaW50 cm9kdWNlIGl0LCBpdCdzIGFscmVhZHkgaW4gdGhlIFBDRSBhcmNoaXRlY3R1cmUuIFRoYXQncyBh IGZhY3QuIFlvdSBtYXkgZGlzYWdyZWUuIFlvdSBhcmUsIG9mIGNvdXJzZSwgZW50aXRsZWQgdG8g eW91ciBvd24gb3BpbmlvbnMsIGJ1dCBub3QgdG8geW91ciBvd24gZmFjdHMuDQoNCkkgdHJpZWQg dG8gZXhwbGFpbiBkZWxlZ2F0aW9uIGluIHRoaXMgZW1haWwgdGhyZWFkIGFzIGNsZWFybHkgYXMg SSBjb3VsZC4gUGxlYXNlIHJlLXJlYWQgaXQsIGFuZCBpZiB5b3UgZG9uJ3QgdW5kZXJzdGFuZCBz b21ldGhpbmcsIGFzayBhIHBvaW50ZWQgcXVlc3Rpb24uIElmIHlvdSBkaXNhZ3JlZSB3aXRoIHNv bWV0aGluZyBpIHdyb3RlLCBwbGVhc2UgYWRkcmVzcyB0aGF0IGNsZWFybHkuIFRoZW4gd2UgY2Fu IGhhdmUgYSBtZWFuaW5nZnVsIGRpc2N1c3Npb24uIEJ1dCBwbGVhc2UgZG8gbm90IHRyeSB0byBy ZXNldCB0aGUgZGlzY3Vzc2lvbiB0byB3aXRoIGdlbmVyYWwgc3RhdGVtZW50cy4NCg0KQW5kIHRo ZW4gdGhlIFdHIHdpbGwvY2FuIGRpc2N1c3MgbW9yZSB3aGV0aGVyIHRoaXMgobBkZWxlZ2F0aW9u obEgaXMgbmVlZGVkIG9yIG5vdCAoYW5kIHdoZXRoZXIgdGhpcyChsGRlbGVnYXRpb26hsSBpcyBp biB0aGUgc2NvcGUgb2YgdGhlIGV4aXN0aW5nIGNoYXJ0ZXIpLg0KDQpXaGVyZSBoYXZlIHlvdSBi ZWVuIHdoZW4gdGhlIFdHIGRpc2N1c3NlZCBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2U/DQoN Cg0KQmVzdCBSZWdhcmRzDQoNCkZhdGFpDQoNClRoYW5rcywNCkphbg0KDQq3orz+yMs6IEphbiBN ZWR2ZWQgKGptZWR2ZWQpIFttYWlsdG86am1lZHZlZEBjaXNjby5jb21dDQq3osvNyrG85DogMjAx MsTqMTHUwjEwyNUgMDoyNw0KytW8/sjLOiBGYXRhaSBaaGFuZw0Ks63LzTogT3NjYXIgR29ueqii bGV6IGRlIERpb3M7IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPg0K1vfM4jogUmU6 IFtQY2VdIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0UsIHJlbGF0aW9uIHRvIFdHIGNoYXJ0 ZXIgYW5kIG9waW5pb24gYWJvdXQgc3RhdGVmdWwgUENFDQoNCkZhaXRhbCwNCg0KT24gTm92IDks IDIwMTIsIGF0IDEyOjIwIEFNLCBGYXRhaSBaaGFuZyB3cm90ZToNCg0KDQo+VGhlIGRlbGVnYXRp b24gb2YgTFNQIGNvbnRyb2wgdG8gYSBQQ0UgaXMgKmltcGxpY2l0KiBpbiBSRkM0NjU1LiBXaGVu IGEgUENDIHNlbmRzIGEgUENSZXEgbWVzc2FnZSB0byBhIFBDRSByZXF1ZXN0aW5nIHBhdGggY29t cHV0YXRpb24gKGFuZCBwYXJhbWV0ZXIgc2V0dGluZykgZm9yIGFuIExTUCwgaXQgZWZmZWN0aXZl bHkNCj4gZGVsZWdhdGVzIGNvbnRyb2wgb3ZlciB0aGF0IExTUCB0byB0aGUgUENFLiBUaGUgZGVs ZWdhdGlvbiBpcyB2YWxpZCBmb3Igb25lIHJlcXVlc3QgKGFuZCBvbmUgcGF0aCBjb21wdXRhdGlv bikgb25seS4NCg0KW0ZhdGFpXSBJIGRvbid0IHRoaW5rIHRoYXQgUkZDNDY1NSBjYW4gc3VwcG9y dCBkZWxlZ2F0aW9uIG9mIExTUCAqY29udHJvbCogKGV2ZW4gaW1wbGljaXRseSkuIEEgUENDIHNl bmRzIGEgUENSZXEgdG8gYSBQQ0UsIGl0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGlzIExTUCBpcyBk ZWxlZ2F0ZWQgdG8gdGhlIFBDRS4NCg0KQnkgcmVxdWVzdGluZyBhIHBhdGggY29tcHV0YXRpb24g ZnJvbSBhIFBDRSwgdGhlIFBDQyBnaXZlcyB0aGUgUENFIGF1dGhvcml0eSB0byBkZXRlcm1pbmUg dGhlIEVSTywgTFNQIEJhbmR3aWR0aCwgcHJvdGVjdGlvbiwgTFNQIHNldHVwIGFuZCBob2xkIHBy aW9yaXRpZXMsIGV0Yy4gVGhlIFBDRSBpcyB0aGUgZW50aXR5IHRoYXQgZGV0ZXJtaW5lcyB0aGVz ZSBwYXJhbWV0ZXJzIC0gd291bGQgeW91IGFncmVlPw0KDQpOb3csIHdoZXRoZXIgd2UgdXNlICJj b250cm9sIiwgImF1dGhvcml0eSIsICJwb3dlciIsICJtYW5kYXRlIiwgd2hhdGV2ZXIgLSB0aGF0 IGRvZXMgbm90IGNoYW5nZSB0aGUgZmFjdCB0aGF0IHRoZSBQQ0MgYXNrcyB0aGUgUENDIHRvIGRl dGVybWluZSB3aGF0IHRoZSBMU1AgcGFyYW1ldGVycyBhcmUsIGFuZCB0aGUgUENFIGRldGVybWlu ZXMgd2hhdCB0aGUgTFNQIHBhcmFtZXRlcnMgYXJlLiBUaGF0J3Mgd2hhdCB3ZSBjYWxsIGRlbGVn YXRpb24gLSB0aGUgUENDICJkZWxlZ2F0ZXMiIHRoZSBjb21wdXRhdGlvbiBvZiBMU1AgcGF0aCBh bmQgZGV0ZXJtaW5hdGlvbiBvZiBMU1AgcGFyYW1ldGVycyB0byB0aGUgUENFLg0KDQpNeSBlbWFp bCBzdGF0ZXMgYSBsaXR0bGUgbGF0ZXI6ICJ0aGUgUENDIG1heSBvciBtYXkgbm90IHVzZSB0aGUg TFNQIHBhdGgvcGFyYW1ldGVycyB0aGF0IGl0IGdvdCBmcm9tIHRoZSBQQ0UiLiBXZSBhbGwgYWdy ZWUgdGhhdCB0aGUgUENDIGhhcyB0aGUgdWx0aW1hdGUgY29udHJvbCBvdmVyIHRoZSBMU1AgLSBp dCBtYXkgdGFrZSB0aGUgZGlyZWN0aW9ucyBmcm9tIHRoZSBQQ0UsIGl0IG1heSBub3QuDQoNCmRy YWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZSBkb2VzIG5vdCBjaGFuZ2UgYW55IG9mIHRoaXMuIFRo ZSBQQ0MgZ2l2ZXMgdGhlIFBDRSB0aGUgY29udHJvbC9hdXRob3JpdHkvbWFuZGF0ZS9wb3dlciB0 byBkZXRlcm1pbmUgdGhlIExTUCdzIHBhcmFtZXRlci4gQnV0LCByYXRoZXIgdGhhbiBkb2luZyB0 aGlzIGltcGxpY2l0bHkgYnkgcmVxdWVzdGluZyB0aGUgUENFIHRvIGRldGVybWluZSB0aG9zZSBw YXJhbWV0ZXJzIChpbiBhIFBDUmVxIG1lc3NhZ2UpLCBpdCBkb2VzIGl0IGV4cGxpY2l0bHkuIERl bGVnYXRpb24gZG9lcyBub3QgY2hhbmdlIHRoZSBwYXJhZGlnbSBzZXQgYnkgUkZDNDY1NSBhbmQg UkZDNTQ0MCAtIGJ1dCBpbiBhZGRpdGlvbiB0byBMU1AgcGFyYW1ldGVycywgaXQgYWxsb3dzIHRo ZSBQQ0UgdG8gZGV0ZXJtaW5lIHRoZSB0aW1pbmcgb2YgdGhlIExTUCBzZXR1cC4NCg0KSWYgeW91 IGRvbid0IGxpa2UgdGhlIHRlcm0gImRlbGVnYXRpb24iLCBwbGVhc2Ugc3VnZ2VzdCBhbm90aGVy IG9uZS4gSSBkb24ndCBwYXJ0aWN1bGFybHkgY2FyZSB3aGF0IHdlIGNhbGwgdGhlIG1lY2hhbmlz bS4NCg0KDQoNClRoYW5rcywNCkphbg0KDQoNCg0K --_000_ACC8AB2D98C05F4E9FBDA092017D97FC150A1438xmbalnx10ciscoc_ Content-Type: text/html; charset="gb2312" Content-ID: <2B64A6DAF42EFA41946622230A64032D@cisco.com> Content-Transfer-Encoding: quoted-printable Fatai,

On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote:

Hi Jan,

You said:

=3D>By= requesting a path computation from a PCE, the PCC gives the PCE authority = to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorit= ies, etc. The PCE is the entity that determines these parameters - would you agree?=

[Fatai] Sorry, I don=A1=AFt agree. The p= arameters (LSP bandwidth, protection, etc) are the constraints sent from PC= C to PCE for *path computation*.

Please re-read rfc5440. A PCRep *may* contain all the above objects. There = is nothing in the RFC5440 saying the PCE could not set these parameters as = it sees fit - even change the BANDWIDTH parameter suggested by a PCC. =

For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE M= UST not return a path with e.g, 100Mbps, ie., the PCE *cannot determine* these parameters. The ERO is the p= ath information (path list) that PCE returns to PCC after path computation.=

Please re-read rfc5440 - BANDWIDTH and all other LSP parameters a= re *optional* on PCReq. A use case where a PCC does not include BANDWIDTH o= n the PCReq message and leaves the determination of a path's bandwidth to t= he PCE is well within the spec. And as I said above, a PCRep may optionally contain bandwidth and other LSP param= eters, not just the ERO.

Even if we say that the only thing that the PCE does is path computati= on, the PCC *delegates* path computation to the PCE. That means, delegation= - as a concept - has been a part of the PCE architecture from the very beg= inning. Therefore, your arguments above about bandwidth, etc. are moot.

If you want to introduce *delegation<= /b>* function (whatever we call it), the delegation definintion should be d= efined clearly.

We don't have to introduce it, it's already in the PCE architecture. That's= a fact. You may disagree. You are, of course, entitled to your own opinion= s, but not to your own facts.

I tried to explain delegation in this email thread as clearly as I cou= ld. Please re-read it, and if you don't understand something, ask a pointed= question. If you disagree with something i wrote, please address that clea= rly. Then we can have a meaningful discussion. But please do not try to reset the discussion to with general = statements.

And then the WG will/can discuss more wh= ether this =A1=B0delegation=A1=B1 is needed or not (and whether this =A1=B0= delegation=A1=B1 is in the scope of the existing charter).

Where have you been when the WG discussed draft-ietf-pce-stateful-pce?=

Best Regards

Fatai

Thanks,

Jan

=B7=A2=BC=FE=C8=CB: Jan Medved (jmedved) [mailto:j= medved@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C210=C8=D5 0:27
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2= lez de Dios;&nbs= p;pce@ietf.org
=D6=F7=CC=E2: Re: [Pce] Questions abo= ut stateful PCE, relation to WG charter and opinion about stateful PCE=

Faital,

On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:

>The delegation of LSP control to a PCE is *implicit* in RFC46= 55. When a PCC sends a PCReq message to a PCE requesting path computation (= and parameter setting) for an LSP, it effectively

> delegates control over that LSP to the PCE. The delegation i= s valid for one request (and one path computation) only.<= /div>

[Fatai] I don't think that RFC4655 can s= upport delegation of LSP *control* (even implicitly). A PCC sends a PCReq t= o a PCE, it does not mean that this LSP is delegated to the PCE.

By reques= ting a path computation from a PCE, the PCC gives the PCE authority to dete= rmine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, et= c. The PCE is the entity that determines these parameters - would you agree?=

Now, whet= her we use "control", "authority", "power", &= quot;mandate", whatever - that does not change the fact that the PCC asks the PCC to determine what the LSP= parameters are, and the PCE determines what the LSP parameters are. That's what we call d= elegation - the PCC "delegates" the computation of LSP path and determination of LSP parameters to the PCE.<= span lang=3D"EN-US">

My email = states a little later: "

draft-ietf-pce-stateful-pce does = not change any of this. The PCC gives the PCE the control/authority/mandate= /power to determine the LSP's parameter. But, rather than doing this implicitly by requesting the PCE to determine = those parameters (in a PCReq message), it does it explicitly. Delegation do= es not change the paradigm set by RFC4655 and RFC5440 - but in addition to = LSP parameters, it allows the PCE to determine the timing of the LSP setup.

If you don't like the term "= delegation", please suggest another one. I don't particularly care wha= t we call the mechanism.

Thanks,

Jan

--_000_ACC8AB2D98C05F4E9FBDA092017D97FC150A1438xmbalnx10ciscoc_-- From zhangfatai@huawei.com Sun Nov 11 22:12:43 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D3321F8532 for ; Sun, 11 Nov 2012 22:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.269 X-Spam-Level: ** X-Spam-Status: No, score=2.269 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7aboc1HcrxZ for ; Sun, 11 Nov 2012 22:12:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3459C21F8413 for ; Sun, 11 Nov 2012 22:12:41 -0800 (PST) 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 ALL05873; Mon, 12 Nov 2012 06:12:37 +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; Mon, 12 Nov 2012 06:12:12 +0000 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 06:12:16 +0000 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.218]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 14:12:08 +0800 From: Fatai Zhang To: "Jan Medved (jmedved)" Thread-Topic: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Thread-Index: Ac29M0Ug4djLg+GXRUWVnAOlC+tbMAAg2IOAAAGpR4AABbR2AAAfI24QAADYnIAAitdk4P//osoA//9rkyA= Date: Mon, 12 Nov 2012 06:12:07 +0000 Message-ID: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.85] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF83582EF2ASZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: [Pce] =?gb2312?b?tPC4tDogIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0Us?= =?gb2312?b?IHJlbGF0aW9uIHRvIFdHIGNoYXJ0ZXIgYW5kIG9waW5pb24gYWJvdXQgc3Rh?= =?gb2312?b?dGVmdWwgUENF?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 06:12:43 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF83582EF2ASZXEML552MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQpbUkZDNTQ0MF0gc2F5czoNCklmIHRoZSByZXF1ZXN0ZWQgYmFuZHdpZHRoIGlz IGVxdWFsIHRvIDAsIHRoZSBCQU5EV0lEVEggb2JqZWN0IGlzIG9wdGlvbmFsLiBDb252ZXJzZWx5 LCBpZiB0aGUgcmVxdWVzdGVkIGJhbmR3aWR0aCBpcyBub3QgZXF1YWwgdG8gMCwgICB0aGUgUENS ZXEgbWVzc2FnZSBNVVNUIGNvbnRhaW4gYSBCQU5EV0lEVEggb2JqZWN0Lg0KDQpJIGRvbqGvdCB0 aGluayB0aGlzIG1lYW5zIHRoYXQgUENFIGNhbiBzZXQgdGhlIGJhbmR3ZGl0aC4gQWxsIHRoZSBw YXJhdGVybWV0ZXMgKGVpdGhlciBvcHRpb25hbCBvciBtYW5kYXRvcnkpICBzZW50IGZyb20gUEND IHRvIFBDRSBpbiB0aGUgUENSZXEgYXJlIHRoZSBjb250cmFuaXRzIHRoYXQgd2lsbCBiZSB0YWtl biBpbnRvIGFjY2NvdW50IGZvciBQQ0UgdG8gcGVyZm9ybSBwYXRoIGNvbXB1dGlvbi4NCg0KSW4g YWRkaXRpb24sIEkgd291bGQgbGlrZSB0byByZW1pbmQgdGhhdCAqc2V0KiAhPSAqZGVsZWdhdGlv biosIG1heWJlIHdlIHN0cmF5IGEgbGl0dGxlIGZyb20gdGhlIHBvaW50LCA6KQ0KDQoNCg0KQmVz dCBSZWdhcmRzDQoNCkZhdGFpDQoNCreivP7IyzogSmFuIE1lZHZlZCAoam1lZHZlZCkgW21haWx0 bzpqbWVkdmVkQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDEyxOoxMdTCMTLI1SAxMzowOQ0KytW8 /sjLOiBGYXRhaSBaaGFuZw0Ks63LzTogT3NjYXIgR29ueqiibGV6IGRlIERpb3M7IHBjZUBpZXRm Lm9yZw0K1vfM4jogUmU6IFtQY2VdIFF1ZXN0aW9ucyBhYm91dCBzdGF0ZWZ1bCBQQ0UsIHJlbGF0 aW9uIHRvIFdHIGNoYXJ0ZXIgYW5kIG9waW5pb24gYWJvdXQgc3RhdGVmdWwgUENFDQoNCkZhdGFp LA0KDQpPbiBOb3YgMTEsIDIwMTIsIGF0IDY6NTYgUE0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KDQoN CkhpIEphbiwNCllvdSBzYWlkOg0KPT5CeSByZXF1ZXN0aW5nIGEgcGF0aCBjb21wdXRhdGlvbiBm cm9tIGEgUENFLCB0aGUgUENDIGdpdmVzIHRoZSBQQ0UgYXV0aG9yaXR5IHRvIGRldGVybWluZSB0 aGUgRVJPLCBMU1AgQmFuZHdpZHRoLCBwcm90ZWN0aW9uLCBMU1Agc2V0dXAgYW5kIGhvbGQgcHJp b3JpdGllcywgZXRjLiBUaGUgUENFIGlzIHRoZSBlbnRpdHkgdGhhdCBkZXRlcm1pbmVzIHRoZXNl IHBhcmFtZXRlcnMgLSB3b3VsZCB5b3UgYWdyZWU/DQoNCltGYXRhaV0gU29ycnksIEkgZG9uoa90 IGFncmVlLiBUaGUgcGFyYW1ldGVycyAoTFNQIGJhbmR3aWR0aCwgcHJvdGVjdGlvbiwgZXRjKSBh cmUgdGhlIGNvbnN0cmFpbnRzIHNlbnQgZnJvbSBQQ0MgdG8gUENFIGZvciAqcGF0aCBjb21wdXRh dGlvbiouDQoNClBsZWFzZSByZS1yZWFkIHJmYzU0NDAuIEEgUENSZXAgKm1heSogY29udGFpbiBh bGwgdGhlIGFib3ZlIG9iamVjdHMuIFRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIFJGQzU0NDAgc2F5 aW5nIHRoZSBQQ0UgY291bGQgbm90IHNldCB0aGVzZSBwYXJhbWV0ZXJzIGFzIGl0IHNlZXMgZml0 IC0gZXZlbiBjaGFuZ2UgdGhlIEJBTkRXSURUSCBwYXJhbWV0ZXIgc3VnZ2VzdGVkIGJ5IGEgUEND Lg0KDQoNCkZvciBleGFtcGxlLCBhIFBDQyBzZW5kcyBhIFBDUmVxIHRvIHJlcXVlc3QgYSBMU1Ag d2l0aCBiYW5kd2lkdGggMUdwYnMsIGFuZCB0aGVuIHRoZSBQQ0UgTVVTVCBub3QgcmV0dXJuIGEg cGF0aCB3aXRoIGUuZywgMTAwTWJwcywgaWUuLCB0aGUgUENFICpjYW5ub3QgZGV0ZXJtaW5lKiB0 aGVzZSBwYXJhbWV0ZXJzLiAgVGhlIEVSTyBpcyB0aGUgcGF0aCBpbmZvcm1hdGlvbiAocGF0aCBs aXN0KSB0aGF0IFBDRSByZXR1cm5zIHRvIFBDQyBhZnRlciBwYXRoIGNvbXB1dGF0aW9uLg0KDQpQ bGVhc2UgcmUtcmVhZCByZmM1NDQwIC0gQkFORFdJRFRIIGFuZCBhbGwgb3RoZXIgTFNQIHBhcmFt ZXRlcnMgYXJlICpvcHRpb25hbCogb24gUENSZXEuIEEgdXNlIGNhc2Ugd2hlcmUgYSBQQ0MgZG9l cyBub3QgaW5jbHVkZSBCQU5EV0lEVEggb24gdGhlIFBDUmVxIG1lc3NhZ2UgYW5kIGxlYXZlcyB0 aGUgZGV0ZXJtaW5hdGlvbiBvZiBhIHBhdGgncyBiYW5kd2lkdGggdG8gdGhlIFBDRSBpcyB3ZWxs IHdpdGhpbiB0aGUgc3BlYy4gQW5kIGFzIEkgc2FpZCBhYm92ZSwgYSBQQ1JlcCBtYXkgb3B0aW9u YWxseSBjb250YWluIGJhbmR3aWR0aCBhbmQgb3RoZXIgTFNQIHBhcmFtZXRlcnMsIG5vdCBqdXN0 IHRoZSBFUk8uDQoNCkV2ZW4gaWYgd2Ugc2F5IHRoYXQgdGhlIG9ubHkgdGhpbmcgdGhhdCB0aGUg UENFIGRvZXMgaXMgcGF0aCBjb21wdXRhdGlvbiwgdGhlIFBDQyAqZGVsZWdhdGVzKiBwYXRoIGNv bXB1dGF0aW9uIHRvIHRoZSBQQ0UuIFRoYXQgbWVhbnMsIGRlbGVnYXRpb24gLSBhcyBhIGNvbmNl cHQgLSBoYXMgYmVlbiBhIHBhcnQgb2YgdGhlIFBDRSBhcmNoaXRlY3R1cmUgZnJvbSB0aGUgdmVy eSBiZWdpbm5pbmcuIFRoZXJlZm9yZSwgeW91ciBhcmd1bWVudHMgYWJvdmUgYWJvdXQgYmFuZHdp ZHRoLCBldGMuIGFyZSBtb290Lg0KDQpJZiB5b3Ugd2FudCB0byBpbnRyb2R1Y2UgKmRlbGVnYXRp b24qIGZ1bmN0aW9uICh3aGF0ZXZlciB3ZSBjYWxsIGl0KSwgdGhlIGRlbGVnYXRpb24gZGVmaW5p bnRpb24gc2hvdWxkIGJlIGRlZmluZWQgY2xlYXJseS4NCg0KV2UgZG9uJ3QgaGF2ZSB0byBpbnRy b2R1Y2UgaXQsIGl0J3MgYWxyZWFkeSBpbiB0aGUgUENFIGFyY2hpdGVjdHVyZS4gVGhhdCdzIGEg ZmFjdC4gWW91IG1heSBkaXNhZ3JlZS4gWW91IGFyZSwgb2YgY291cnNlLCBlbnRpdGxlZCB0byB5 b3VyIG93biBvcGluaW9ucywgYnV0IG5vdCB0byB5b3VyIG93biBmYWN0cy4NCg0KSSB0cmllZCB0 byBleHBsYWluIGRlbGVnYXRpb24gaW4gdGhpcyBlbWFpbCB0aHJlYWQgYXMgY2xlYXJseSBhcyBJ IGNvdWxkLiBQbGVhc2UgcmUtcmVhZCBpdCwgYW5kIGlmIHlvdSBkb24ndCB1bmRlcnN0YW5kIHNv bWV0aGluZywgYXNrIGEgcG9pbnRlZCBxdWVzdGlvbi4gSWYgeW91IGRpc2FncmVlIHdpdGggc29t ZXRoaW5nIGkgd3JvdGUsIHBsZWFzZSBhZGRyZXNzIHRoYXQgY2xlYXJseS4gVGhlbiB3ZSBjYW4g aGF2ZSBhIG1lYW5pbmdmdWwgZGlzY3Vzc2lvbi4gQnV0IHBsZWFzZSBkbyBub3QgdHJ5IHRvIHJl c2V0IHRoZSBkaXNjdXNzaW9uIHRvIHdpdGggZ2VuZXJhbCBzdGF0ZW1lbnRzLg0KDQoNCkFuZCB0 aGVuIHRoZSBXRyB3aWxsL2NhbiBkaXNjdXNzIG1vcmUgd2hldGhlciB0aGlzIKGwZGVsZWdhdGlv bqGxIGlzIG5lZWRlZCBvciBub3QgKGFuZCB3aGV0aGVyIHRoaXMgobBkZWxlZ2F0aW9uobEgaXMg aW4gdGhlIHNjb3BlIG9mIHRoZSBleGlzdGluZyBjaGFydGVyKS4NCg0KV2hlcmUgaGF2ZSB5b3Ug YmVlbiB3aGVuIHRoZSBXRyBkaXNjdXNzZWQgZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlPw0K DQoNCg0KQmVzdCBSZWdhcmRzDQoNCkZhdGFpDQoNClRoYW5rcywNCkphbg0KDQoNCreivP7Iyzog SmFuIE1lZHZlZCAoam1lZHZlZCkgW21haWx0bzpqbWVkdmVkQGNpc2NvLmNvbV0NCreiy83Ksbzk OiAyMDEyxOoxMdTCMTDI1SAwOjI3DQrK1bz+yMs6IEZhdGFpIFpoYW5nDQqzrcvNOiBPc2NhciBH b256qKJsZXogZGUgRGlvczsgcGNlQGlldGYub3JnPG1haWx0bzpwY2VAaWV0Zi5vcmc+DQrW98zi OiBSZTogW1BjZV0gUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBDRSwgcmVsYXRpb24gdG8gV0cg Y2hhcnRlciBhbmQgb3BpbmlvbiBhYm91dCBzdGF0ZWZ1bCBQQ0UNCg0KRmFpdGFsLA0KDQpPbiBO b3YgOSwgMjAxMiwgYXQgMTI6MjAgQU0sIEZhdGFpIFpoYW5nIHdyb3RlOg0KDQoNCg0KPlRoZSBk ZWxlZ2F0aW9uIG9mIExTUCBjb250cm9sIHRvIGEgUENFIGlzICppbXBsaWNpdCogaW4gUkZDNDY1 NS4gV2hlbiBhIFBDQyBzZW5kcyBhIFBDUmVxIG1lc3NhZ2UgdG8gYSBQQ0UgcmVxdWVzdGluZyBw YXRoIGNvbXB1dGF0aW9uIChhbmQgcGFyYW1ldGVyIHNldHRpbmcpIGZvciBhbiBMU1AsIGl0IGVm ZmVjdGl2ZWx5DQo+IGRlbGVnYXRlcyBjb250cm9sIG92ZXIgdGhhdCBMU1AgdG8gdGhlIFBDRS4g VGhlIGRlbGVnYXRpb24gaXMgdmFsaWQgZm9yIG9uZSByZXF1ZXN0IChhbmQgb25lIHBhdGggY29t cHV0YXRpb24pIG9ubHkuDQoNCltGYXRhaV0gSSBkb24ndCB0aGluayB0aGF0IFJGQzQ2NTUgY2Fu IHN1cHBvcnQgZGVsZWdhdGlvbiBvZiBMU1AgKmNvbnRyb2wqIChldmVuIGltcGxpY2l0bHkpLiBB IFBDQyBzZW5kcyBhIFBDUmVxIHRvIGEgUENFLCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQgdGhpcyBM U1AgaXMgZGVsZWdhdGVkIHRvIHRoZSBQQ0UuDQoNCkJ5IHJlcXVlc3RpbmcgYSBwYXRoIGNvbXB1 dGF0aW9uIGZyb20gYSBQQ0UsIHRoZSBQQ0MgZ2l2ZXMgdGhlIFBDRSBhdXRob3JpdHkgdG8gZGV0 ZXJtaW5lIHRoZSBFUk8sIExTUCBCYW5kd2lkdGgsIHByb3RlY3Rpb24sIExTUCBzZXR1cCBhbmQg aG9sZCBwcmlvcml0aWVzLCBldGMuIFRoZSBQQ0UgaXMgdGhlIGVudGl0eSB0aGF0IGRldGVybWlu ZXMgdGhlc2UgcGFyYW1ldGVycyAtIHdvdWxkIHlvdSBhZ3JlZT8NCg0KTm93LCB3aGV0aGVyIHdl IHVzZSAiY29udHJvbCIsICJhdXRob3JpdHkiLCAicG93ZXIiLCAibWFuZGF0ZSIsIHdoYXRldmVy IC0gdGhhdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGZhY3QgdGhhdCB0aGUgUENDIGFza3MgdGhlIFBD QyB0byBkZXRlcm1pbmUgd2hhdCB0aGUgTFNQIHBhcmFtZXRlcnMgYXJlLCBhbmQgdGhlIFBDRSBk ZXRlcm1pbmVzIHdoYXQgdGhlIExTUCBwYXJhbWV0ZXJzIGFyZS4gVGhhdCdzIHdoYXQgd2UgY2Fs bCBkZWxlZ2F0aW9uIC0gdGhlIFBDQyAiZGVsZWdhdGVzIiB0aGUgY29tcHV0YXRpb24gb2YgTFNQ IHBhdGggYW5kIGRldGVybWluYXRpb24gb2YgTFNQIHBhcmFtZXRlcnMgdG8gdGhlIFBDRS4NCg0K TXkgZW1haWwgc3RhdGVzIGEgbGl0dGxlIGxhdGVyOiAidGhlIFBDQyBtYXkgb3IgbWF5IG5vdCB1 c2UgdGhlIExTUCBwYXRoL3BhcmFtZXRlcnMgdGhhdCBpdCBnb3QgZnJvbSB0aGUgUENFIi4gV2Ug YWxsIGFncmVlIHRoYXQgdGhlIFBDQyBoYXMgdGhlIHVsdGltYXRlIGNvbnRyb2wgb3ZlciB0aGUg TFNQIC0gaXQgbWF5IHRha2UgdGhlIGRpcmVjdGlvbnMgZnJvbSB0aGUgUENFLCBpdCBtYXkgbm90 Lg0KDQpkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UgZG9lcyBub3QgY2hhbmdlIGFueSBvZiB0 aGlzLiBUaGUgUENDIGdpdmVzIHRoZSBQQ0UgdGhlIGNvbnRyb2wvYXV0aG9yaXR5L21hbmRhdGUv cG93ZXIgdG8gZGV0ZXJtaW5lIHRoZSBMU1AncyBwYXJhbWV0ZXIuIEJ1dCwgcmF0aGVyIHRoYW4g ZG9pbmcgdGhpcyBpbXBsaWNpdGx5IGJ5IHJlcXVlc3RpbmcgdGhlIFBDRSB0byBkZXRlcm1pbmUg dGhvc2UgcGFyYW1ldGVycyAoaW4gYSBQQ1JlcSBtZXNzYWdlKSwgaXQgZG9lcyBpdCBleHBsaWNp dGx5LiBEZWxlZ2F0aW9uIGRvZXMgbm90IGNoYW5nZSB0aGUgcGFyYWRpZ20gc2V0IGJ5IFJGQzQ2 NTUgYW5kIFJGQzU0NDAgLSBidXQgaW4gYWRkaXRpb24gdG8gTFNQIHBhcmFtZXRlcnMsIGl0IGFs bG93cyB0aGUgUENFIHRvIGRldGVybWluZSB0aGUgdGltaW5nIG9mIHRoZSBMU1Agc2V0dXAuDQoN CklmIHlvdSBkb24ndCBsaWtlIHRoZSB0ZXJtICJkZWxlZ2F0aW9uIiwgcGxlYXNlIHN1Z2dlc3Qg YW5vdGhlciBvbmUuIEkgZG9uJ3QgcGFydGljdWxhcmx5IGNhcmUgd2hhdCB3ZSBjYWxsIHRoZSBt ZWNoYW5pc20uDQoNCg0KDQpUaGFua3MsDQpKYW4NCg0KDQoNCg== --_000_F82A4B6D50F9464B8EBA55651F541CF83582EF2ASZXEML552MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jan,

= ;

[RFC5440] = says:

I= f the requested bandwidth is equal to 0, the BANDWIDTH object is optional. = Conversely, if the requested bandwidth is not equal to 0, the PCReq message MUST contain a BANDWIDTH object.

= ;

I don=A1=AFt think this mea= ns that PCE can set the bandwdith. All the paratermetes (either optional or mandatory) sent from PCC to PCE in the PCReq are the contranits that will be taken into acc= count for PCE to perform path compution.

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">In addition, I would like to remin= d that *set* !=3D *delegation*, maybe we stray a little from the point, J

Best Regards

Fatai

= ;

=B7=A2=BC=FE=C8= =CB: Jan Medved (jmedved) [mailto:jmedved@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C212=C8=D5 = 13:09
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2lez de Dios; pce@ietf.org
=D6=F7=CC=E2: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinio= n about stateful PCE

Fatai,

On Nov 11, 2012, at 6:56 PM, Fa= tai Zhang wrote:

Hi Jan,

You said:<= /span>

=3D>By requesting a path computation f= rom a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwi= dth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

[Fatai] So= rry, I don=A1=AFt agree. The parameters (LSP bandwidth, protection, etc) ar= e the constraints sent from PCC to PCE for *path computation*.

Please re-read rfc5440. A PCRep= *may* contain all the above objects. There is nothing in the RFC5440 sayin= g the PCE could not set these parameters as it sees fit - even change the B= ANDWIDTH parameter suggested by a PCC.

For exampl= e, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g= , 100Mbps, ie., the PCE *cannot determine* these parameters. T= he ERO is the path information (path list) that PCE returns to PCC after pa= th computation.

Please re-read rfc5440 - B= ANDWIDTH and all other LSP parameters are *optional* on PCReq. A use case w= here a PCC does not include BANDWIDTH on the PCReq message and leaves the d= etermination of a path's bandwidth to the PCE is well within the spec. And as I said above, a PCRep may optionally c= ontain bandwidth and other LSP parameters, not just the ERO.

Even if we say that the only th= ing that the PCE does is path computation, the PCC *delegates* path computa= tion to the PCE. That means, delegation - as a concept - has been a part of= the PCE architecture from the very beginning. Therefore, your arguments above about bandwidth, etc. are = moot.

If you want to introduce *<= b>delegation* function (whatever we call it), the delegation definintion should be defined clearly.

We don't have to introduce it, = it's already in the PCE architecture. That's a fact. You may disagree. You = are, of course, entitled to your own opinions, but not to your own facts.&n= bsp;

<= /p>

I tried to explain delegation i= n this email thread as clearly as I could. Please re-read it, and if you do= n't understand something, ask a pointed question. If you disagree with some= thing i wrote, please address that clearly. Then we can have a meaningful discussion. But please do not try to reset t= he discussion to with general statements.

And then the WG will/can di= scuss more whether this =A1=B0delegation=A1=B1 is needed or not (and whethe= r this =A1=B0delegation=A1=B1 is in the scope of the existing charter).

Where have you been when the WG= discussed draft-ietf-pce-stateful-pce?

Best Regards

Fatai

Thanks,

Jan

=B7=A2=BC=FE=C8= =CB: <= span lang=3D"EN-US" style=3D"font-size:10.0pt">Jan Medved (jmedved) [mailto= :jmedved@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C210=C8=D5 = 0:27
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2lez de Dios; pce@ie= tf.org
=D6=F7=CC=E2: Re: [Pce] Questions about stateful PCE, relation to WG charter and opi= nion about stateful PCE

Faital,

On Nov 9, 2012, at 12:20 AM, Fa= tai Zhang wrote:

>The delegation of LS= P control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq messa= ge to a PCE requesting path computation (and parameter setting) for an LSP, it effectively

> delegates control o= ver that LSP to the PCE. The delegation is valid for one request (and one p= ath computation) only.

[Fatai] I = don't think that RFC4655 can support delegation of LSP *control* (even impl= icitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE.

If you don't like the term "delegation", please suggest a= nother one. I don't particularly care what we call the mechanism.

Thanks,

Jan

--_000_F82A4B6D50F9464B8EBA55651F541CF83582EF2ASZXEML552MBXchi_-- From edc@google.com Sun Nov 11 22:49:56 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148F921F854F for ; Sun, 11 Nov 2012 22:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.162 X-Spam-Level: X-Spam-Status: No, score=-96.162 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, 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 eI3Ur8oeszmR for ; Sun, 11 Nov 2012 22:49:52 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 40E1121F854D for ; Sun, 11 Nov 2012 22:49:52 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so1343643qaa.10 for ; Sun, 11 Nov 2012 22:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wrHSuAjw0fFDnId16h1E6553Uqt196Bws/pvnJ4/2gU=; b=AyFiri3xeOPMrOeNRzEvhYCYHD7k8oyn4p5nLdpaD2E7GvqQJaFC+QZcBnYERAGDcv xomW+UmsQc7zFDtN0FPzcX/3kKqwJIbGv76KX22vuo3xoBJnoG1ZIfoFMoA1CuNovnYO BO8Se1jxZDMEyYqG+uWq6K2GUSB1MCNNbjZf2zl/GTXulOpaeujpG9H1T1ocUGzWGO/D HUndzEpa85twcMrMAMVWKxg0ndPFSi5fs0vhqUB7q+y7KQ+9gSD0raGUNqayA1CFPCMt tCcavcCsirdon1sLv7UwZcHCoBFZfOaqu/il9HUpAkkbaH4EoDMuEFZZ1B3cYX4y+e/Z UC6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wrHSuAjw0fFDnId16h1E6553Uqt196Bws/pvnJ4/2gU=; b=F7rrdj8OCnXrEcsWbh75VfNcF3xZtYahC7//XRLtWNimClS5aHjdHV/w18xwFhfGy3 S3i//1k61qx75vJ8Bgf9P9QTy1pQU/z0XwojFyDl/gqBSnk4w9bjgnHpu7fj0wRbrZ+n qJV6BImqzSQbLUllhZrLziHV/tCqzKw1aCHsX+FM+PTN6fw1Lc4e/ajQ+40juPUpotzY GQhsf3vwBDeval4+etaWyX+bHkDnW3TrbJYDG628oCyBtbG+gEWZFjY7bEo7Ba4ycQD0 Evj59a0vnNLvqkLLqn5rDL7nQq4CvN2rtVoUkTqxL92kLQs0vwC/SdHJ24fBSyEuU9Kk 23LA== Received: by 10.229.252.207 with SMTP id mx15mr209135qcb.56.1352702991726; Sun, 11 Nov 2012 22:49:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.75.41 with HTTP; Sun, 11 Nov 2012 22:49:11 -0800 (PST) In-Reply-To: References: <7CFF94B047D8864CB6268315034E35DE08A7198A@EX10-MB2-MAD.hi.inet> <509C26DD.3000107@orange.com> <7CFF94B047D8864CB6268315034E35DE08A72718@EX10-MB2-MAD.hi.inet>

From: Edward Crabbe Date: Sun, 11 Nov 2012 22:49:11 -0800 Message-ID: To: Fatai Zhang Content-Type: multipart/alternative; boundary=0016e68dea554efa0f04ce46b560 X-Gm-Message-State: ALoCoQkqvRNgqSPJGjW1iPaTK3jwxPkpdGKseM880B72Nt5o+Lh81J90LRx5szzegxD0KegVc3KNoRXPwWuckLjqWIPuwW6b2JZPts9g2ujY+wWHf2wDueZJyrRlAdAOwxGre20uPdg8A9A9yJ3r0+Mil/DYqcE5I0FLis3Z6WIiVH3LMc1kCb4DIpqEcLxUL9gcveePfsuo Cc: "pce@ietf.org" Subject: Re: [Pce] =?gb2312?b?tPC4tDogUXVlc3Rpb25zIGFib3V0IHN0YXRlZnVsIFBDRSwg?= =?gb2312?b?cmVsYXRpb24gdG8gV0cgY2hhcnRlciBhbmQgb3BpbmlvbiBhYm91?= =?gb2312?b?dCBzdGF0ZWZ1bCBQQ0U=?= X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 06:49:56 -0000 --0016e68dea554efa0f04ce46b560 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable > > > In addition, I would like to remind that **set** !=3D **delegation**, may= be > we stray a little from the point, J > Please clearly explain your perception of the difference. > **** > > ** ** > > ** ** > > ** ** > > Best Regards**** > > ** ** > > Fatai**** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* Jan Medved (jmedved) [mailto:jmedved@cisco.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2012=C4=EA11=D4=C212=C8=D5 13:09 > *=CA=D5=BC=FE=C8=CB:* Fatai Zhang > *=B3=AD=CB=CD:* Oscar Gonz=A8=A2lez de Dios; pce@ietf.org > *=D6=F7=CC=E2:* Re: [Pce] Questions about stateful PCE, relation to WG ch= arter and > opinion about stateful PCE**** > > ** ** > > Fatai, **** > > ** ** > > On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote:**** > > > > **** > > Hi Jan,**** > > You said:**** > > =3D>By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree?**** > > **** > > [Fatai] Sorry, I don=A1=AFt agree. The parameters (LSP bandwidth, protect= ion, > etc) are the constraints sent from PCC to PCE for **path computation**. *= * > ** > > ** ** > > Please re-read rfc5440. A PCRep *may* contain all the above objects. Ther= e > is nothing in the RFC5440 saying the PCE could not set these parameters a= s > it sees fit - even change the BANDWIDTH parameter suggested by a PCC. ***= * > > > > **** > > For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, > and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE *= *cannot > determine** these parameters. The ERO is the path information (path > list) that PCE returns to PCC after path computation.**** > > **** > > Please re-read rfc5440 - BANDWIDTH and all other LSP parameters are > *optional* on PCReq. A use case where a PCC does not include BANDWIDTH on > the PCReq message and leaves the determination of a path's bandwidth to t= he > PCE is well within the spec. And as I said above, a PCRep may optionally > contain bandwidth and other LSP parameters, not just the ERO.**** > > ** ** > > Even if we say that the only thing that the PCE does is path computation, > the PCC *delegates* path computation to the PCE. That means, delegation - > as a concept - has been a part of the PCE architecture from the very > beginning. Therefore, your arguments above about bandwidth, etc. are moot= . > **** > > ** ** > > If you want to introduce **delegation** function (whatever we call it), > the delegation definintion should be defined clearly. **** > > ** ** > > We don't have to introduce it, it's already in the PCE architecture. > That's a fact. You may disagree. You are, of course, entitled to your own > opinions, but not to your own facts. **** > > **** > > I tried to explain delegation in this email thread as clearly as I could. > Please re-read it, and if you don't understand something, ask a pointed > question. If you disagree with something i wrote, please address that > clearly. Then we can have a meaningful discussion. But please do not try = to > reset the discussion to with general statements.**** > > > > **** > > And then the WG will/can discuss more whether this =A1=B0delegation=A1=B1= is needed > or not (and whether this =A1=B0delegation=A1=B1 is in the scope of the ex= isting > charter).**** > > **** > > Where have you been when the WG discussed draft-ietf-pce-stateful-pce?***= * > > > > **** > > **** > > Best Regards**** > > **** > > Fatai**** > > **** > > Thanks,**** > > Jan**** > > > > **** > > *=B7=A2=BC=FE=C8=CB:* Jan Medved (jmedved) [mailto:jmedved@cisco.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2012=C4=EA11=D4=C210=C8=D5 0:27 > *=CA=D5=BC=FE=C8=CB:* Fatai Zhang > *=B3=AD=CB=CD:* Oscar Gonz=A8=A2lez de Dios; pce@ietf.org > *=D6=F7=CC=E2:* Re: [Pce] Questions about stateful PCE, relation to WG ch= arter and > opinion about stateful PCE**** > > **** > > Faital,**** > > **** > > On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:**** > > > > > **** > > >The delegation of LSP control to a PCE is *implicit* in RFC4655. When a > PCC sends a PCReq message to a PCE requesting path computation (and > parameter setting) for an LSP, it effectively**** > > > delegates control over that LSP to the PCE. The delegation is valid for > one request (and one path computation) only.**** > > **** > > [Fatai] I don't think that RFC4655 can support delegation of LSP *control= * > (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that th= is > LSP is delegated to the PCE.**** > > **** > > By requesting a path computation from a PCE, the PCC gives the PCE > authority to determine the ERO, LSP Bandwidth, protection, LSP setup and > hold priorities, etc. The PCE is the entity that determines these > parameters - would you agree?**** > > **** > > Now, whether we use "control", "authority", "power", "mandate", whatever = - > that does not change the fact that the PCC asks the PCC to determine what > the LSP parameters are, and the PCE determines what the LSP parameters > are. That's what we call delegation - the PCC "delegates" the computation > of LSP path and determination of LSP parameters to the PCE.**** > > **** > > My email states a little later: "the PCC may or may not use the LSP > path/parameters that it got from the PCE". We all agree that the PCC has > the ultimate control over the LSP - it may take the directions from the > PCE, it may not. **** > > **** > > draft-ietf-pce-stateful-pce does not change any of this. The PCC gives th= e > PCE the control/authority/mandate/power to determine the LSP's parameter. > But, rather than doing this implicitly by requesting the PCE to determine > those parameters (in a PCReq message), it does it explicitly. Delegation > does not change the paradigm set by RFC4655 and RFC5440 - but in addition > to LSP parameters, it allows the PCE to determine the timing of the LSP > setup.**** > > **** > > If you don't like the term "delegation", please suggest another one. I > don't particularly care what we call the mechanism. **** > > **** > > **** > > **** > > Thanks,**** > > Jan**** > > **** > > **** > > ** ** > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --0016e68dea554efa0f04ce46b560 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1f497d">In addition, I would like to remin= d that *set* !=3D *delegation*, maybe we stray a little from the point, J

Please clearly explain your perception of the difference.

=

=

=

Best Regards<= /span>

=

Fatai<= /p>

&nb= sp;

=B7=A2=BC=FE=C8=CB: Jan Medved (jmedved) [mailto:jmedved@cisco.com]

=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA11=D4=C212=C8=D5 13:09

=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2lez de Dios; pce@ietf.org
=D6=F7=CC=E2: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinio= n about stateful PCE

Fatai,

On Nov 11, 2012, at 6:56 PM, Fa= tai Zhang wrote:

Hi Jan,

You said:<= /span>

=3D>By requesting a path computation f= rom a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwi= dth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

[Fatai] So= rry, I don’t agree. The parameters (LSP bandwidth, protection, etc) a= re the constraints sent from PCC to PCE for *path computation*.

Please re-read rfc5440. A PCRep= *may* contain all the above objects. There is nothing in the RFC5440 sayin= g the PCE could not set these parameters as it sees fit - even change the B= ANDWIDTH parameter suggested by a PCC.

For exampl= e, a PCC sends a&nbs= p;PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g= , 100Mbps, ie., the PCE *cannot determine* these parameters. T= he ERO is the path information (path list) that PCE returns to PCC after pa= th computation.

Please re-read rfc5440 - B= ANDWIDTH and all other LSP parameters are *optional* on PCReq. A use case w= here a PCC does not include BANDWIDTH on the PCReq message and leaves the d= etermination of a path's bandwidth to the PCE is well within the spec. And as I said above, a PCRep may optionally c= ontain bandwidth and other LSP parameters, not just the ERO.<= /span>

Even if we say that the only th= ing that the PCE does is path computation, the PCC *delegates* path computa= tion to the PCE. That means, delegation - as a concept - has been a part of= the PCE architecture from the very beginning. Therefore, your arguments above about bandwidth, etc. are = moot.

If you want to introduce *<= b>delegation* function (whatever we call it), the delegation definintion should be defined clearly. =

We don't have to introduce = it, it's already in the PCE architecture. That's a fact. You may di= sagree. You are, of course, entitled to your own opinions, but not to your = own facts.

I tried to explain delegation i= n this email thread as clearly as I could. Please re-read it, and if you do= n't understand something, ask a pointed question. If you disagree with = something i wrote, please address that clearly. Then we can have a meaningful discussion. But please do not try to reset t= he discussion to with general statements.

And then the WG will/can di= scuss more whether this “delegation” is needed or not (and whet= her this “delegation” is in the scope of the existing charter).

Where have you been when the WG= discussed draft-ietf-pce-stateful-pce?

Best Regards

Fatai

Thanks,

Jan

=B7=A2=BC=FE=C8= =CB: Jan Medved (jmedved) [mailto:jmedved@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA= 11=D4=C210=C8=D5 0:27
=CA=D5=BC=FE=C8=CB: Fatai Zhang
=B3=AD=CB=CD: Oscar Gonz=A8=A2lez de Dios; pce@ietf.org
=D6=F7=CC=E2: Re: [Pce] Questions about s= tateful PCE, relation to WG charter and opinion about stateful PCE

Faital,

On Nov 9, 2012, at 12:20 AM, Fa= tai Zhang wrote:

>The delegation of LS= P control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq messa= ge to a PCE requesting path computation (and parameter setting) for an LSP, it effectively

> delegates control o= ver that LSP to the PCE. The delegation is valid for one request (and one p= ath computation) only.

[Fatai] I = don't think that RFC4655 can support delegation of LSP *control* (even = implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE.

By requesting a path computation from a P= CE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, pr= otection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree?

Now, whether we use "control", = "authority", "power", "mandate", whatever - t= hat does not change the fact that the PCC asks the PCC to determ= ine what the LSP parameters are, and <= /span>the PCE determines what the LSP parameters are. That= 's what we call delegation - the PCC "delegates" the computation of LSP path and determination of LSP parameters to the PCE= .

My email states a little later: "the PCC may or may not use the LSP path/parameters that it got from the PCE". We all agree that = the PCC has the ultimate control over the LSP - it may take the directions = from the PCE, it may not.

draft-ietf-pce-stat= eful-pce does not change any of this. The PCC gives the PCE the control/aut= hority/mandate/power to determine the LSP's parameter. But, rather than doing this implicitly by request= ing the PCE to determine those parameters (in a PCReq message), it does it = explicitly. Delegation does not change the paradigm set by RFC4655 and RFC5= 440 - but in addition to LSP parameters, it allows the PCE to determine the timing of the LSP setup.<= span lang=3D"EN-US">

If you don't li= ke the term "delegation", please suggest another one. I don't= particularly care what we call the mechanism.

Thanks,

Jan

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce