Hi Ina & = Authors,

Now that we have new WG charter, I think it is a good tim= e to clarify applicability of PCE-Stateful.

Following are some of m= y observations that can be considered in your next revisions of draft:

1. We need to scope the PCE-Stateful applicability, i.e., clarify= explicitly where vanilla PCE can be sufficient or PCE-Stateful could be an= overkill.

=A0=A0=A0 - Similarly, it would be nice to describe dep= loyments of Passive Stateful PCE and=A0 with Active Stateful PCE separately=

I think draft describes goodness of Stateful well, however, = it should provide guidelines for choosing right set of PCE-stateful feature= s.

Few basic applications (I am not sur= e this draft covers them explicitly) from PCC Scale point of view:

2. I think draft should describe on performance w/ PCE-Stateful
=A0= =A0=A0 i.e., How PCE Stateful helps in dynamic changes compared to NMS base= d.

3. One obvious applicability of Active PCE-Stateful would b= e : config scaling. Operators do not have to maintain tons of LSP configura= tion on the box.

4. LSP monitoring is less expensive with PCE Stateful, as PCE is = expected to maintain complete state.
This reduces burden on routers.

Thanks,
Ravi

<= /div>

http://www.google= .com/profiles/pratiravi

On Sun, Jun 2, 2013 at 11:36 AM, Adrian = Farrel <adrian@olddog.co.uk> wrote:

Ina, WG,
=A0
Pleased to see people thinking about applicab= ility and use cases. IMHO, not enough attention is paid to why we are doing= things and how they will be used.

=A0<= /p>
Thanks for the work, a= nd hope people will review it (especially service providers!)=

=A0<= /p>
Adrian

=A0<= /p>

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf O= f Ina Minei
Sent: 26 May 2013 22:52
To: pce@ietf.org
Subject: [Pce] New version o= f the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-0= 4

=A0=
A new version of the stateful pce applicability draft was posted= yesterday.

=A0
= In the interest of ma= king progress on this document, the authors would like to solicit review, c= omments and discussion from the working group, before the next IETF meeting= .

=A0
= =A0

URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04= .txt

Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://= datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app=

Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.= ietf.org/html/draft-zhang-pce-stateful-pce-app-04<= /p>
Diff:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-pce-stateful-pce-app-04

=A0
=A0
I= na and Xian on behalf of all the authors

=A0

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

--14dae93d9446ee92d004de569d0d-- From zhang.xian@huawei.com Tue Jun 4 18:26:23 2013 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 60BBB21F99EC for ; Tue, 4 Jun 2013 18:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRL6s3nmr3Tk for ; Tue, 4 Jun 2013 18:26:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88821F99D5 for ; Tue, 4 Jun 2013 18:26:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASC67545; Wed, 05 Jun 2013 01:26:16 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 02:25:26 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 02:26:12 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Wed, 5 Jun 2013 09:26:02 +0800 From: "Zhangxian (Xian)" To: Ravi Torvi , "adrian@olddog.co.uk" Thread-Topic: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04 Thread-Index: AQHOX6cNfwKpW/9GHUW2jbtNhciy/pklPJUAgAEVW+A= Date: Wed, 5 Jun 2013 01:26:01 +0000 Message-ID: References: <70BDAD02381BA54CA31315A2A26A7AD3037AFA02@BLUPRD0511MB436.namprd05.prod.outlook.com> <036001ce5fa7$01a6aa40$04f3fec0$@olddog.co.uk> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BEDF8szxeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04 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: Wed, 05 Jun 2013 01:26:23 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BEDF8szxeml510mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFJhdmksDQoNCiAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSB1c2VmdWwgc3VnZ2Vz dGlvbnMuIFBsZWFzZSBmaW5kIG15IHJlcGx5IGlubGluZToNCg0KUmVnYXJkcywNClhpYW4NCg0K RnJvbTogcGNlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFJhdmkgVG9ydmkNClNlbnQ6IDIwMTPE6jbUwjXI1SAwOjMyDQpUbzogYWRy aWFuQG9sZGRvZy5jby51aw0KQ2M6IHBjZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQY2VdIE5l dyB2ZXJzaW9uIG9mIHRoZSBzdGF0ZWZ1bCBwY2UgYXBwbGljYWJpbGl0eSBkcmFmdCAtIGRyYWZ0 LXpoYW5nLXBjZS1zdGF0ZWZ1bC1wY2UtYXBwLTA0DQoNCkhpIEluYSAmIEF1dGhvcnMsDQpOb3cg dGhhdCB3ZSBoYXZlIG5ldyBXRyBjaGFydGVyLCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRv IGNsYXJpZnkgYXBwbGljYWJpbGl0eSBvZiBQQ0UtU3RhdGVmdWwuDQoNCkZvbGxvd2luZyBhcmUg c29tZSBvZiBteSBvYnNlcnZhdGlvbnMgdGhhdCBjYW4gYmUgY29uc2lkZXJlZCBpbiB5b3VyIG5l eHQgcmV2aXNpb25zIG9mIGRyYWZ0Og0KMS4gV2UgbmVlZCB0byBzY29wZSB0aGUgUENFLVN0YXRl ZnVsIGFwcGxpY2FiaWxpdHksIGkuZS4sIGNsYXJpZnkgZXhwbGljaXRseSB3aGVyZSB2YW5pbGxh IFBDRSBjYW4gYmUgc3VmZmljaWVudCBvciBQQ0UtU3RhdGVmdWwgY291bGQgYmUgYW4gb3Zlcmtp bGwuDQogICAgLSBTaW1pbGFybHksIGl0IHdvdWxkIGJlIG5pY2UgdG8gZGVzY3JpYmUgZGVwbG95 bWVudHMgb2YgUGFzc2l2ZSBTdGF0ZWZ1bCBQQ0UgYW5kICB3aXRoIEFjdGl2ZSBTdGF0ZWZ1bCBQ Q0Ugc2VwYXJhdGVseQ0KSSB0aGluayBkcmFmdCBkZXNjcmliZXMgZ29vZG5lc3Mgb2YgU3RhdGVm dWwgd2VsbCwgaG93ZXZlciwgaXQgc2hvdWxkIHByb3ZpZGUgZ3VpZGVsaW5lcyBmb3IgY2hvb3Np bmcgcmlnaHQgc2V0IG9mIFBDRS1zdGF0ZWZ1bCBmZWF0dXJlcy4NCiMjIzogSW4gdGhpcyB2ZXJz aW9uLCB3ZSBkaWQgZXhwbGljaXRseSBkZXNjcmliZSB0aGVzZSB0d28gZGlmZmVyZW50IGtpbmRz IG9mIHN0YXRlZnVsIFBDRXMgaW4gYSB2YXJpZXR5IG9mIHVzZSBjYXNlcyBzaW5jZSB0aGV5IGhh dmUgZGlmZmVyZW50IGNhcGFiaWxpdGllcy4gSWYgeW91IGhhdmUgbG9vayBhdCB0aGUgdXNlIGNh c2VzIHdlIGhhdmUgZnJvbSBTZWN0aW9uIDUsIHlvdSBzaG91bGQgYmUgYWJsZSB0byBmaW5kIHN1 Y2ggdXBkYXRlLiBJZiB0aGVyZSBhcmUgc3RpbGwgdGhpbmdzIG1pc3NpbmcgLCBwbGVhc2UgbGV0 IHVzIGtub3cuDQojIyM6IEFzIGZvciB3aGVyZSB0aGUgc3RhdGVmdWwgUENFIGlzIGFwcGxpY2Fi bGUsIEkgdGhpbmsgdGhlIHdob2xlIGRvY3VtZW50IGlzIHRyeWluZyB0byBzYXkgaXRzIG5lY2Vz c2l0eSwgSSBkbyBub3Qgc2VlIHdoeSB3ZSBuZWVkIHRvIG5hbWUgZXhhbXBsZXMgd2hlcmUgaXQg aXMgbm90IG5lZWRlZC4gSG93ZXZlciwgd2UgZG8gc3RhdGUgdGhlIHByb3MgYW5kIGNvbnMgb2Yg c3RhdGVmdWwgUENFcyBoZXJlIGFuZCB0aGVyZSBhcyB3ZWxsIGFzIGluIHRoZSB1c2UgY2FzZXMg c28gYXMgdG8gbWFrZSBpdCBsZXNzIGFkdmVydGlzaW5nIGFzIEpQIHN1Z2dlc3RlZCBpbiBsYXN0 IElFVEYuDQoNCkZldyBiYXNpYyBhcHBsaWNhdGlvbnMgKEkgYW0gbm90IHN1cmUgdGhpcyBkcmFm dCBjb3ZlcnMgdGhlbSBleHBsaWNpdGx5KSBmcm9tIFBDQyBTY2FsZSBwb2ludCBvZiB2aWV3Og0K DQoyLiBJIHRoaW5rIGRyYWZ0IHNob3VsZCBkZXNjcmliZSBvbiBwZXJmb3JtYW5jZSB3LyBQQ0Ut U3RhdGVmdWwNCiAgICBpLmUuLCBIb3cgUENFIFN0YXRlZnVsIGhlbHBzIGluIGR5bmFtaWMgY2hh bmdlcyBjb21wYXJlZCB0byBOTVMgYmFzZWQuDQojIyM6IEluIHRoaXMgZG9jdW1lbnQsIHdlIGFy ZSBjb21wYXJpbmcgd2l0aCBhIHN0YXRlbGVzcyBQQ0UsIG5vdCBOTVMuIFdoeSBkbyB5b3UgdGhp bmsgdGhlcmUgaXMgc3VjaCBhIG5lZWQgdG8gY29tcGFyZSB3aXRoIHRoZSBsYXR0ZXI/IElNSE8s ICBzdGF0ZWZ1bCBQQ0VzIGFyZSBub3QgdHJ5aW5nIHRvIHJlcGxhY2UgTk1TIHNpbmNlIHRoZXkg aGF2ZSBkaWZmZXJlbnQgdXRpbGl0aWVzLiBKdXN0IGFzIHlvdSBtZW50aW9uZWQgdGhhdCBzdGF0 ZWZ1bCBQQ0VzIGNhbiBoZWxwIHdpdGggZHluYW1pYyBjaGFuZ2VzLCB3aGljaCBJIGRvIG5vdCB0 aGluayBpdCBpcyB3aGF0IE5NUyBpcyBtYWlubHkgdXNlZCBmb3IuDQozLiBPbmUgb2J2aW91cyBh cHBsaWNhYmlsaXR5IG9mIEFjdGl2ZSBQQ0UtU3RhdGVmdWwgd291bGQgYmUgOiBjb25maWcgc2Nh bGluZy4gT3BlcmF0b3JzIGRvIG5vdCBoYXZlIHRvIG1haW50YWluIHRvbnMgb2YgTFNQIGNvbmZp Z3VyYXRpb24gb24gdGhlIGJveC4NCiMjIzogSSBkbyBub3QgZ2V0IHlvdXIgcG9pbnQsIGFyZSB5 b3UgY29tcGFyaW5nIE5NUy1iYXNlZCBjb25maWd1cmF0aW9uIHdpdGggc3RhdGVmdWwgUENFLWJh c2VkIGNvbmZpZ3VyYXRpb24/DQo0LiBMU1AgbW9uaXRvcmluZyBpcyBsZXNzIGV4cGVuc2l2ZSB3 aXRoIFBDRSBTdGF0ZWZ1bCwgYXMgUENFIGlzIGV4cGVjdGVkIHRvIG1haW50YWluIGNvbXBsZXRl IHN0YXRlLg0KVGhpcyByZWR1Y2VzIGJ1cmRlbiBvbiByb3V0ZXJzLg0KIyMjOiBBZ2Fpbiwgd2hh dCBlbnRpdHkgYXJlIHlvdSBjb21wYXJpbmcgc3RhdGVmdWwgUENFIHdpdGg/IENvdWxkIHlvdSBl bGFib3JhdGUgbW9yZT8gSSBoYXZlbqGvdCB0aG91Z2h0IGFib3V0IHRoaXMgYmVmb3JlLiBCVFcs IHRoaXMgZHJhZnQgd29ya3MgZm9yIGJvdGggTVBMUy1URSBhbmQgR01QTFMgY29udHJvbGxlZCBu ZXR3b3Jrcy4gU28gSSB3b25kZXIgd2hlbiB5b3Ugc2F5IKGwdGhpcyByZWR1Y2VzIGJ1cmRlbiBv biByb3V0ZXJzobEsIGRvIHlvdSBtZWFuIHRoaXMgYXBwbGljYXRpb25zIGFyZSBvbmx5IHBvc3Np YmxlIHdpdGggTVBMUy1URSBuZXR3b3Jrcz8NClRoYW5rcywNClJhdmkNCg0KDQpodHRwOi8vd3d3 Lmdvb2dsZS5jb20vcHJvZmlsZXMvcHJhdGlyYXZpDQoNCk9uIFN1biwgSnVuIDIsIDIwMTMgYXQg MTE6MzYgQU0sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWs+PiB3cm90ZToNCkluYSwgV0csDQoNClBsZWFzZWQgdG8gc2VlIHBlb3Bs ZSB0aGlua2luZyBhYm91dCBhcHBsaWNhYmlsaXR5IGFuZCB1c2UgY2FzZXMuIElNSE8sIG5vdCBl bm91Z2ggYXR0ZW50aW9uIGlzIHBhaWQgdG8gd2h5IHdlIGFyZSBkb2luZyB0aGluZ3MgYW5kIGhv dyB0aGV5IHdpbGwgYmUgdXNlZC4NCg0KVGhhbmtzIGZvciB0aGUgd29yaywgYW5kIGhvcGUgcGVv cGxlIHdpbGwgcmV2aWV3IGl0IChlc3BlY2lhbGx5IHNlcnZpY2UgcHJvdmlkZXJzISkNCg0KQWRy aWFuDQoNCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwY2UtYm91bmNlc0BpZXRm Lm9yZz4gW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGNlLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSW5hIE1pbmVpDQpTZW50OiAyNiBNYXkgMjAxMyAyMjo1Mg0K VG86IHBjZUBpZXRmLm9yZzxtYWlsdG86cGNlQGlldGYub3JnPg0KU3ViamVjdDogW1BjZV0gTmV3 IHZlcnNpb24gb2YgdGhlIHN0YXRlZnVsIHBjZSBhcHBsaWNhYmlsaXR5IGRyYWZ0IC0gZHJhZnQt emhhbmctcGNlLXN0YXRlZnVsLXBjZS1hcHAtMDQNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgc3Rh dGVmdWwgcGNlIGFwcGxpY2FiaWxpdHkgZHJhZnQgd2FzIHBvc3RlZCB5ZXN0ZXJkYXkuDQoNCklu IHRoZSBpbnRlcmVzdCBvZiBtYWtpbmcgcHJvZ3Jlc3Mgb24gdGhpcyBkb2N1bWVudCwgdGhlIGF1 dGhvcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IHJldmlldywgY29tbWVudHMgYW5kIGRpc2N1c3Np b24gZnJvbSB0aGUgd29ya2luZyBncm91cCwgYmVmb3JlIHRoZSBuZXh0IElFVEYgbWVldGluZy4N Cg0KDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXpoYW5nLXBjZS1zdGF0ZWZ1bC1wY2UtYXBwLTA0LnR4dA0KU3RhdHVzOiAgICAgICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXBjZS1zdGF0ZWZ1 bC1wY2UtYXBwDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLXBjZS1zdGF0ZWZ1bC1wY2UtYXBwLTA0DQpEaWZmOiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpoYW5nLXBjZS1zdGF0ZWZ1bC1wY2Ut YXBwLTA0DQoNCg0KSW5hIGFuZCBYaWFuIG9uIGJlaGFsZiBvZiBhbGwgdGhlIGF1dGhvcnMNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUGNlIG1h aWxpbmcgbGlzdA0KUGNlQGlldGYub3JnPG1haWx0bzpQY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjZQ0KDQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BEDF8szxeml510mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Ravi,

= ;

&nbs= p; Thank you very much for the useful suggestions. Please find my reply inl= ine:

= ;

Regards,

Xian<= /o:p>

= ;

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ravi Torvi
Sent: 2013=C4=EA6=D4=C25=C8= =D5 0:32
To: adrian@olddog.co.uk
Cc: pce@ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability dra= ft - draft-zhang-pce-stateful-pce-app-04

Hi Ina & Authors,

= Now that we have new WG charter, I think it is a good time to clarify appli= cability of PCE-Stateful.

Following are some of my observations that can be considered in your next r= evisions of draft:

1. We need to scope the PCE-Sta= teful applicability, i.e., clarify explicitly where vanilla PCE can be suff= icient or PCE-Stateful could be an overkill.

= - Similarly, it would be nice to describe deployments of= Passive Stateful PCE and with Active Stateful PCE separately

I think draft describes goodnes= s of Stateful well, however, it should provide guidelines for choosing righ= t set of PCE-stateful features.

###: In= this version, we did explicitly describe these two different kinds of stat= eful PCEs in a variety of use cases since they have different capabilities.= If you have look at the use cases we have from Section 5, you should be able to find such update. If there are = still things missing , please let us know.

###: As= for where the stateful PCE is applicable, I think the whole document is tr= ying to say its necessity, I do not see why we need to name examples where = it is not needed. However, we do state the pros and cons of stateful PCEs here and there as well as in the use ca= ses so as to make it less advertising as JP suggested in last IETF.

= ;

= Few basic applications (I am not sure this draft covers them explicitly) fr= om PCC Scale point of view:

2. I think draft should describe on performance w/ PCE-Stateful
i.e., How PCE Stateful helps in dynamic changes compared= to NMS based.

###: In this document, we are comparing with a statele= ss PCE, not NMS. Why do you think there is such a need to compare with the latter? IMHO, stateful PCEs are not trying to replace NMS s= ince they have different utilities. Just as you mentioned that stateful PCE= s can help with dynamic changes, which I do not think it is what NMS is mai= nly used for.

= 3. One obvious applicability of Active PCE-Stateful would be : config scali= ng. Operators do not have to maintain tons of LSP configuration on the box.=

###: I do not get your point, are you comparing NMS-ba= sed configuration with stateful PCE-based configuration?<= /p>

= 4. LSP monitoring is less expensive with PCE Stateful, as PCE is expected t= o maintain complete state.
This reduces burden on routers.

###: Again, what entity are you comparing stateful PCE= with? Could you elaborate more? I haven=A1=AFt thought about this before. BTW, this draft works for both MPLS-TE and GMPLS controlled networ= ks. So I wonder when you say =A1=B0this reduces burden on routers=A1=B1, do= you mean this applications are only possible with MPLS-TE networks? =

Thanks,
Ravi

http://www.google.com/profiles/pratiravi

On Sun, Jun 2, 2013 at 11:36 AM= , Adrian Farrel <adrian@olddog.co.uk> wrote:

Ina, WG,

Pleased to see people th= inking about applicability and use cases. IMHO, not enough attention is paid to why we are doing things and how they will be used.

Thanks for the work, and= hope people will review it (especially service providers!)

Adrian

From: pce-bounces@ietf.= org [mailto:p= ce-bounces@ietf.org] On Behalf Of Ina Minei
Sent: 26 May 2013 22:52
To: pce@ietf.org
Subject: [Pce] New version of the stateful pce applicability draft -= draft-zhang-pce-stateful-pce-app-04=

A new version of the stateful pce applicability draft was posted yesterd= ay.

In the interest of making progress on this document, the authors would l= ike to solicit review, comments and discussion from the working group, before the next IETF meeting.

URL: &n= bsp; http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt=

Status: http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app=

Htmlized: http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04

Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-pce-stateful-pce-app-04<= /span>

Ina and Xian on behalf of all the auth= ors

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

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BEDF8szxeml510mbxchi_-- From adrian@olddog.co.uk Fri Jun 7 05:34:47 2013 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 06D8921F8633 for ; Fri, 7 Jun 2013 05:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm4QXBvDlEaj for ; Fri, 7 Jun 2013 05:34:42 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id BD96421F92E7 for ; Fri, 7 Jun 2013 05:34:39 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57CYbC4017132 for ; Fri, 7 Jun 2013 13:34:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57CYacs017090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 7 Jun 2013 13:34:37 +0100 From: "Adrian Farrel" To: Date: Fri, 7 Jun 2013 13:34:31 +0100 Message-ID: <0ac301ce637b$5c5cdcc0$15169640$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5jexypj6w8u1EESVKly549kv9Y9A== Content-Language: en-gb Subject: [Pce] FW: Supplementary question on draft-ietf-pce-gmpls-aps-req X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:34:47 -0000 Strangely I sent this email to CCAMP not PCE. Here is the thread for your information. Adrian > -----Original Message----- > From: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] > Sent: 06 June 2013 08:59 > To: adrian@olddog.co.uk; draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] Supplementary question on draft-ietf-pce-gmpls-aps-req > > Dear Adrian, > > > Just talking about this I-D with someone and we wondered where and how you > > see the RSVP-TE ASSOCIATION object with your work. > > IMHO, ASSOCIATION object should be handled by RSVP-TE handling process on > an > LSP head-end node, separated from PCC process on this node. > However, PCC should indicate a protection type how a protecting LSP protects > the protected one in PCReq as described in 3.1(7) and 3.2(3). In this case, > the PCC process receives both calculated protecting and protected routes > from PCE, then informs the RSVP-TE process of these routes. After that, > RSVP-TE process should appropriately add ASSOCIATION object to Path messages > for these LSPs. > > If we touch on ASSOCIATION object in this draft, a sentence may be added to > 3.2(3)Roles of the routes as follows. > > When a PCC specifies the protection type of an LSP, the PCE should compute > the working route and the corresponding protection route(s). Therefore, the > PCRep should allow to distinguish the working (nominal) and the protection > routes. According to these routes, RSVP-TE procedure appropriately creates > both the working and the protection LSPs for example with ASSOCIATION object > [RFC6689]. > > Is this reasonable answer? > > Thanks, > Kenichi > -- > Kenichi Ogaki > KDDI | IP Transport Network Development Dept. > +81-(0)80-5945-9138 | www.kddi.com > > > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: Tuesday, June 04, 2013 9:03 PM > > To: draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org > > Cc: ccamp@ietf.org > > Subject: [CCAMP] Supplementary question on draft-ietf-pce-gmpls-aps-req > > > > Hi, > > > > Just talking about this I-D with someone and we wondered where and how you > > see the RSVP-TE ASSOCIATION object with your work. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Fri Jun 7 05:39:04 2013 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 322DF21F918F for ; Fri, 7 Jun 2013 05:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRRRxJLDpZ25 for ; Fri, 7 Jun 2013 05:38:58 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0B421F918C for ; Fri, 7 Jun 2013 05:38:57 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57Ccr1N006080; Fri, 7 Jun 2013 13:38:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57Ccqkq006071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 13:38:53 +0100 From: "Adrian Farrel" To: "'Ogaki, Kenichi'" , Date: Fri, 7 Jun 2013 13:38:47 +0100 Message-ID: <0ac401ce637b$f50fe570$df2fb050$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5je/EkdQHEQaQxTvqEox4WkDCXsg== Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] Supplementary question on draft-ietf-pce-gmpls-aps-req X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:39:04 -0000 Hello again, > IMHO, ASSOCIATION object should be handled by RSVP-TE handling process on > an LSP head-end node, separated from PCC process on this node. > However, PCC should indicate a protection type how a protecting LSP protects > the protected one in PCReq as described in 3.1(7) and 3.2(3). In this case, > the PCC process receives both calculated protecting and protected routes > from PCE, then informs the RSVP-TE process of these routes. After that, > RSVP-TE process should appropriately add ASSOCIATION object to Path messages > for these LSPs. > > If we touch on ASSOCIATION object in this draft, a sentence may be added to > 3.2(3)Roles of the routes as follows. > > When a PCC specifies the protection type of an LSP, the PCE should compute > the working route and the corresponding protection route(s). Therefore, the > PCRep should allow to distinguish the working (nominal) and the protection > routes. According to these routes, RSVP-TE procedure appropriately creates > both the working and the protection LSPs for example with ASSOCIATION object > [RFC6689]. > > Is this reasonable answer? I think that covers the protection use case for the Association object. And it would be good to add it to the document. There are many other uses of the object for associating LSPs with each other. However, if those use cases are not showing up in PCE requirements at the moment, that is fine and we do not need to discuss the object any further in the document. Thanks, Adrian From zhang.xian@huawei.com Sat Jun 8 02:36:52 2013 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 24A3D21F9A4A for ; Sat, 8 Jun 2013 02:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=-3.971, BAYES_50=0.001, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRP1oZuxh-D7 for ; Sat, 8 Jun 2013 02:36:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 35CDC21F9A4B for ; Sat, 8 Jun 2013 02:36:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASF45218; Sat, 08 Jun 2013 09:36: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.7; Sat, 8 Jun 2013 10:36:41 +0100 Received: from SZXEML461-HUB.china.huawei.com (10.82.67.204) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 10:36:40 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml461-hub.china.huawei.com ([10.82.67.204]) with mapi id 14.01.0323.007; Sat, 8 Jun 2013 17:36:23 +0800 From: "Zhangxian (Xian)" To: Ina Minei , "draft-ietf-pce-stateful-pce@tools.ietf.org" Thread-Topic: RE: Xian's comments on draft-ietf-pce-stateful-pce V2 Thread-Index: AQHOZCujXlG56YBkxESzQfxu5jUJFw== Date: Sat, 8 Jun 2013 09:36:22 +0000 Message-ID: References: <70BDAD02381BA54CA31315A2A26A7AD30374F30B@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD30374F30B@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BF3B2szxeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] Xian's comments on draft-ietf-pce-stateful-pce V2 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: Sat, 08 Jun 2013 09:36:52 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BF3B2szxeml510mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEluYSwNCg0KICBUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkgYW5kIHVwZGF0ZSBvbiB0aGUg ZHJhZnQuIFBsZWFzZSBzZWUgbXkgZnVydGhlciBjb21tZW50cyBvbiBzb21lIG9mIHRoZSBwb2lu dHMgaW5saW5lLCBzdGFydGluZyB3aXRoIKGwPlhpYW46obEuDQoNCiAgSSBoYXZlIGFkZGl0aW9u YWwgY29tbWVudHMgb24gVmVyc2lvbiA0LCB3aWxsIHNlbmQgdGhlbSBvdXQgaW4gYSBzZXBhcmF0 ZSBlbWFpbCBzb29uLg0KDQpSZWdhcmRzLA0KWGlhbg0KDQpQUzogIEkgaGF2ZSBhZGRlZCB0aGUg UENFIFdHIG1haWxpbmcgbGlzdCBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHdvcmtpbmcgZ3JvdXAu DQoNCg0KRnJvbTogSW5hIE1pbmVpIFttYWlsdG86aW5hQGp1bmlwZXIubmV0XQ0KU2VudDogMjAx M8TqNNTCM8jVIDQ6MDQNClRvOiBaaGFuZ3hpYW4gKFhpYW4pOyBkcmFmdC1pZXRmLXBjZS1zdGF0 ZWZ1bC1wY2VAdG9vbHMuaWV0Zi5vcmcNCkNjOiBGYXRhaSBaaGFuZzsgTGVleW91bmcNClN1Ympl Y3Q6IFJFOiBYaWFuJ3MgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlDQoN ClhpYW4sDQoNCkFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IGluIHJlcGx5LCBwbGVhc2Ugc2VlIHJl c3BvbnNlcyBpbmxpbmUgYmVsb3csIGxvb2sgZm9yICMjIy4NCg0KRnJvbTogWmhhbmd4aWFuIChY aWFuKSBbbWFpbHRvOnpoYW5nLnhpYW5AaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVi cnVhcnkgMjAsIDIwMTMgMTA6NTcgUE0NClRvOiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2VA dG9vbHMuaWV0Zi5vcmcNCkNjOiBGYXRhaSBaaGFuZzsgTGVleW91bmcNClN1YmplY3Q6DQoNCkhp LCBEZWFyIGFsbCwNCg0KICAgQXMgcHJvbWlzZWQgZHVyaW5nIGxhc3QgSUVURiBtZWV0aW5nLCBJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdC4gVGhlIGZvbGxvd2luZyBpcyBteSBkZXRhaWxlZCBz dWdnZXN0aW9ucyB3aXRoIHByb3ZpZGVkIHRleHQgZm9yIGltcHJvdmluZyB0aGUgZHJhZnQgYXMg d2VsbCBhcyBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgSSBhbSBsb29raW5nIGZvcndhcmQgdG8gaGVh ciBmcm9tIHlvdS4NCg0KKlN1Z2dlc3Rpb25zL0NvbW1lbnRzOg0KDQpTZWN0aW9uIDMuMjoNCm8g IEFsbG93IGEgUENFIHRvIHNwZWNpZnkgcHJvdGVjdGlvbiAvIHJlc3RvcmF0aW9uIHNldHRpbmdz IGZvciBhbGwgTFNQcyB0aGF0IGhhdmUgYmVlbiBkZWxlZ2F0ZWQgdG8gaXQuDQpDb21tZW50OiBU aGlzIG1heSBiZSwgaW5kZWVkLCBhIHJlcXVpcmVtZW50IGZvciBzdGF0ZWZ1bCBQQ0VQIGV4dGVu c2lvbiwgYnV0IGl0IGlzIG5vdCBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQgYXMgcG9pbnRlZCBv dXQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50LiBBbHRlcm5hdGl2ZWx5LCB0aGlzIHNlY3Rpb24gY2Fu IGJlIHJlLXdyaXR0ZW4gYSBiaXQgdG8gbWFrZSB0aGUgT2JqZWN0aXZlIG5vdCBjb25maW5lZCB0 byB0aGlzIGRvY3VtZW50Lg0KDQojIyMgWWVzLCBnb29kIHBvaW50LCB3aWxsIHVwZGF0ZSBpbiB0 aGUgbmV4dCByZXZpc2lvbi4NCg0KU2VjdGlvbiA1LjI6DQpTaW5jZSBpbiBTZWN0aW9uIDQsIGl0 IGlzIGNsZWFybHkgc3RhdGVkIHRoYXQgc3RhdGVmdWwgY2FwYWJpbGl0aWVzIGRpc2NvdmVyeSBp cyBub3QgaW4gdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsIEkgd291bGQgcmVjb21tZW5kIHRv IHJlbW92ZSB0aGUgbGFzdCB0d28gcm93cyBvZiB0aGUgdGFibGUgcHJlc2VudGVkIGluIHRoaXMg c2VjdGlvbi4gTW9yZW92ZXIsIGFkZCBhIHJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgd2hpY2gg ZGVmaW5lcyBzbyB3b3VsZCBhbHNvIGJlIGhlbHBmdWwuDQoNCiMjIyBUaGUgcmVmZXJlbmNlIHRv IHRoZSBkaXNjb3ZlcnkgZHJhZnQgd2FzIGFkZGVkIGluIHZlcnNpb24gMDMgaW4gc2VjdGlvbiA0 LCBzbyBJIHRoaW5rIGl0IGlzIG9rIHRvIGxlYXZlIHRoZSBsYXN0IDIgbGluZXMuDQoNClNlY3Rp b24gNS4zOg0KT2xkOiBMU1AgZGVsZWdhdGlvbiBhbmQgTFNQIHVwZGF0ZSBvcGVyYXRpb25zIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBNQVkgb25seSBiZSB1c2VkIGlmIGJvdGggUENFUCBTcGVh a2VycyBzZXQgdGhlIExTUC1VUERBVEUgRmxhZyBpbiB0aGUgIlN0YXRlZnVsIENhcGFiaWxpdHki IFRMViB0byAnVXBkYXRlcyBBbGxvd2VkIChVIEZsYWcgPSAxKScsIG90aGVyd2lzZSBhIFBDRXJy IHdpdGggY29kZSAiRGVsZWdhdGlvbiBub3QgbmVnb3RpYXRlZCIgKHNlZSBTZWN0aW9uIDguNCkg d2lsbCBiZSBnZW5lcmF0ZWQuDQpOZXc6IExTUCBkZWxlZ2F0aW9uIGFuZCBMU1AgdXBkYXRlIG9w ZXJhdGlvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IE1VU1Qgb25seSBiZSB1c2VkIGlmIGJv dGggUENFUCBTcGVha2VycyBzZXQgdGhlIExTUC1VUERBVEUtQ0FQQUJJTElUWSBGbGFnIGluIHRo ZSAiU3RhdGVmdWwgUENFIENhcGFiaWxpdHkiIFRMViB0byAnVXBkYXRlcyBBbGxvd2VkIChVIEZs YWcgPSAxKScsIG90aGVyd2lzZSBhIFBDRXJyIHdpdGggY29kZSAiRGVsZWdhdGlvbiBub3QgbmVn b3RpYXRlZCIgKHNlZSBTZWN0aW9uIDguNCkgd2lsbCBiZSBnZW5lcmF0ZWQuDQpDb21tZW50OiBG cm9tIFNlY3Rpb24gNy4xLjEsIHRoZSByZXF1aXJlbWVudCBpcyBhIE1VU1Qgbm90IGEgTUFZPw0K DQojIyMgSSBkb26hr3QgYWdyZWUsIGhlcmUgaXMgYW4gZXhwbGFuYXRpb24uIFNlY3Rpb24gNy4x LjEgc2F5cyB0aGUgY2FwYWJpbGl0eSBNVVNUIGJlIGFkdmVydGlzZWQgYnkgYm90aCBlbmRzLiBU aGUgZXh0ZW5zaW9ucyBNQVkgYmUgdXNlZCwgbm90IE1VU1QgYmUgdXNlZC4gQmFzaWNhbGx5LCB5 b3UgY2FuIG5lZ290aWF0ZSB0aGUgY2FwYWJpbGl0eSBhbmQgdGhlbiBkb26hr3QgZG8gYW55IGRl bGVnYXRpb24gb3IgdXBkYXRlLCBhbmQgdGhhdCBpcyBvay4gSWYgeW91IHdhbnQgdG8gdXNlIHRo ZW0sIHlvdSBjYW4sIGJ1dCBvbmx5IGlmIHlvdSBkaWQgdGhlIG5lZ290aWF0aW9uLiAgU28gSSB0 aGluayBpdCBzaG91bGQgYmUgIE1BWS4NCj5YaWFuOiBJIGFncmVlIHdpdGggd2hhdCB5b3UgZXhw bGFpbmVkIGFib3ZlOyBidXQgaGVyZSwgSSB0aG91Z2h0IGl0IGlzIHRhbGtpbmcgYWJvdXQgaG93 IHRvIGhhbmRsZSBlcnJvciBzaXR1YXRpb24uIE15IGludGVycHJldGF0aW9uIG9mIHRoaXMgc2Vu dGVuY2UgaXMgdGhhdCBpdCBpbnRlbmRzIHRvIGxpbWl0IHRoZSBzaXR1YXRpb24gd2hlbiB0aGUg TFNQIGRlbGVnYXRpb24gYW5kIExTUCB1cGRhdGUgb3BlcmF0aW9ucyBNVVNUIGJlIGZvbGxvd2Vk ICh3aGVuIGl0IGlzIGVuYWJsZWQsIG9mIGNvdXJzZSkuIFRoZW4sIHRoZSBydWxlIGlzIG5vdCBm b2xsb3dlZCwgZm9yIGV4YW1wbGUsIGlmIExTUCB1cGRhdGUgb3BlcmF0aW9uIGlzIHVzZWQgd2l0 aG91dCBVPTEsIHRoZW4gZXJyb3Igc2hvdWxkIGJlIHJlcG9ydGVkLiBJcyB0aGF0IHdoYXQgeW91 IGludGVuZCB0byBzYXk/DQoNClNlY3Rpb24gNS40LjGjug0KT2xko7pJZiBhIFBDQydzIExTUCBT dGF0ZSBEYXRhYmFzZSBzdXJ2aXZlZCB0aGUgcmVzdGFydCwgdGhlIFBDQyB3aWxsIGluY2x1ZGUg dGhlIExTUC1EQi1WRVJTSU9OIFRMViBpbiBpdHMgT1BFTiBvYmplY3QgYW5kIHRoZSBUTFYgd2ls bCBjb250YWluIHRoZSBsYXN0IExTUCBTdGF0ZSBEYXRhYmFzZSB2ZXJzaW9uIHNlbnQgb24gYW4g TFNQIFN0YXRlIFVwZGF0ZSBmcm9tIHRoZSBQQ0MgaW4gdGhlIHByZXZpb3VzIFBDRVAgc2Vzc2lv bi4NCk5ld6O6SWYgYSBQQ0MncyBMU1AgU3RhdGUgRGF0YWJhc2Ugc3Vydml2ZWQgdGhlIHJlc3Rh cnQsIHRoZSBQQ0Mgd2lsbCBpbmNsdWRlIHRoZSBMU1AtREItVkVSU0lPTiBUTFYgaW4gaXRzIE9Q RU4gb2JqZWN0IGFuZCB0aGUgVExWIHdpbGwgY29udGFpbiB0aGUgTFNQIFN0YXRlIERhdGFiYXNl IHZlcnNpb24gaW5jbHVkZWQgaW4gaXRzIGxhc3QgTFNQIFN0YXRlIFJlcG9ydCBzZW50IGluIHRo ZSBwcmV2aW91cyBQQ0VQIHNlc3Npb24uDQoNCiMjIyBUaGVyZSB3YXMgYSB0ZXJtaW5vbG9neSBj aGFuZ2UgZnJvbSBsc3Agc3RhdGUgdXBkYXRlIHRvIGxzcCBzdGF0ZSByZXBvcnQgaW4gb25lIG9m IHRoZSB2ZXJ5IGVhcmx5IHZlcnNpb25zIG9mIHRoaXMgZHJhZnQsIGFuZCB0aGUgdGV4dCBzdGls bCBoYWQgYSBmZXcgb2xkIHJlZmVyZW5jZXMuIEkgaGF2ZSBmaXhlZCB0aGVtIGFsbCBub3csIHRo YW5rIHlvdSBmb3IgcG9pbnRpbmcgdGhlbSBvdXQuDQoNCk9sZDogTm90ZSB0aGF0IHRoZSBzYW1l IFN0YXRlIFN5bmNocm9uaXphdGlvbiBzZXF1ZW5jZSB3b3VsZCBoYXBwZW4gaWYgZWl0aGVyIHRo ZSBQQ0Ugb3IgdGhlIFBDRSB3b3VsZCBub3QgaW5jbHVkZSB0aGUgTFNQLURCLVZFUlNJT04gVExW IGluIHRoZWlyIHJlc3BlY3RpdmUgT3BlbiBtZXNzYWdlcy4NCk5ldzogTm90ZSB0aGF0IHRoZSBz YW1lIFN0YXRlIFN5bmNocm9uaXphdGlvbiBzZXF1ZW5jZSB3b3VsZCBoYXBwZW4gaWYgZWl0aGVy IHRoZSBQQ0Ugb3IgdGhlIFBDQyB3b3VsZCBub3QgaW5jbHVkZSB0aGUgTFNQLURCLVZFUlNJT04g VExWIGluIHRoZWlyIHJlc3BlY3RpdmUgT3BlbiBtZXNzYWdlcy4NCg0KIyMjIGZpeGVkIGluIHZl cnNpb24gMDMNCg0KRmlndXJlIDg6IHRoZSChsExTUCBTdGF0ZSBVcGRhdGWhsSBzaG91bGQgYmUg Y2hhbmdlZCB0byChsExTUCBTdGF0ZSBSZXBvcnShsS4NCg0KIyMjIFRoYW5rcyBmb3IgY2F0Y2hp bmcsIHNlZSB0aGUgZXhwbGFuYXRpb24gYWJvdmUuDQoNClNlY3Rpb24gNS41Og0KTFNQcyBhcmUg ZGVsZWdhdGVkIGluZGl2aWR1YWxseSAtIGRpZmZlcmVudCBMU1BzIG1heSBiZSBkZWxlZ2F0ZWQg dG8gZGlmZmVyZW50IFBDRXMsIGFuZCBhbiBMU1AgbWF5IGJlIGRlbGVnYXRlZCB0byBvbmUgb3Ig bW9yZSBQQ0VzLg0KQ29tbWVudDogVG8gYXZvaWQgY29uZnVzaW9uIGFuZCBsaW5rIHRoaXMgYmFj ayB0byBTZWN0aW9uIDMuMiwgSSB3b3VsZCBzdWdnZXN0IHRvIGFkZCB0aGUgZm9sbG93aW5nIHNl bnRlbmNlOg0KSG93ZXZlciwgYSBMU1AgaXMgdW5kZXIgY29udHJvbCBvZiBhIHNpbmdsZSBQQ0Ug YXQgYW55IGdpdmVuIHRpbWUuDQoNCiMjIyBUaGUgdGV4dCBpcyBjbGFyaWZpZWQgaW4gdmVyc2lv biAwMy4NCg0KU2VjdGlvbiA1LjUuMToNCk9sZDogRGVsZWdhdGlvbiBhY2NlcHRhbmNlIGlzIGNv bmZpcm1lZCB3aGVuIHRoZSBQQ0Mgd2lzaGVzIHRvIHVwZGF0ZSB0aGUgTFNQIHZpYSB0aGUgTFNQ IFVwZGF0ZSBSZXF1ZXN0LiAgSWYgYSBQQ0UgZG9lcyBub3QgYWNjZXB0IHRoZSBMU1AgRGVsZWdh dGlvbiwgaXQgTVVTVCBpbW1lZGlhdGVseSByZXNwb25kIHdpdGggYW4gZW1wdHkgTFNQIFVwZGF0 ZSBSZXF1ZXN0IHdoaWNoIGhhcyB0aGUgRGVsZWdhdGUgZmxhZyBzZXQgdG8gMC4NCk5ldzogRGVs ZWdhdGlvbiBhY2NlcHRhbmNlIGlzIGNvbmZpcm1lZCB3aGVuIHRoZSBQQ0Ugc2VuZHMgdGhlIGZp cnN0IExTUCBVcGRhdGUgUmVxdWVzdCB3aXRoIERlbGVnYXRlIGZsYWcgc2V0IHRvIDEuIElmIGEg UENFIGRvZXMgbm90IGFjY2VwdCB0aGUgTFNQIERlbGVnYXRpb24sIGl0IE1VU1QgaW1tZWRpYXRl bHkgcmVzcG9uZCB3aXRoIGFuIGVtcHR5IExTUCBVcGRhdGUgUmVxdWVzdCB3aGljaCBoYXMgdGhl IERlbGVnYXRlIGZsYWcgc2V0IHRvIDAuDQoNCiMjIyBUaGUgdGV4dCBpcyBjbGFyaWZpZWQgaW4g dmVyc2lvbiAwMy4NCj5YaWFuOiBJIGNoZWNrZWQgVmVyc2lvbiA0LCBpdCBkb2VzIG5vdCBmdWxs eSBjYXRjaGVzIG15IGNvbW1lbnQuIFRoZSBkZWxlZ2F0aW9uIGFjY2VwdGFuY2UgY2FuIG9ubHkg YmUgY29uZmlybWVkIHdpdGggcmVjZWl2aW5nIG1lc3NhZ2VzIHNlbnQgZnJvbSBQQ0UsIG5vdCB3 aGVuIFBDRSB3aXNoZXMgdG8gdXBkYXRlIHZpYSB0aGUgTFNQIFVwZGF0ZSBSZXF1ZXN0LiBNYXli ZSwgSSBhbSBiZWluZyBwaWNreS4gU28geW91IGRvIG5vdCBoYXZlIHRvIGZvbGxvdyBteSBzdWdn ZXN0aW9uLCBidXQgYXQgbGVhc3QgZG8gbm90IHVzZSB0aGUgd29yZCChsHdpc2ihsSwgOikuDQoN Cg0KU2VjdGlvbiA2LjKjug0KT2xkOiBBbiBMU1AgVXBkYXRlIFJlcXVlc3QgTVVTVCBjb250YWlu IGFsbCBMU1AgcGFyYW1ldGVycyB0aGF0IGEgUENDIHdpc2hlcyB0byBzZXQgZm9yIHRoZSBMU1Au IEEgUENDIE1BWSBzZXQgbWlzc2luZyBwYXJhbWV0ZXJzIGZyb20gbG9jYWxseSBjb25maWd1cmVk IGRlZmF1bHRzLg0KTmV3OiBBbiBMU1AgVXBkYXRlIFJlcXVlc3QgTVVTVCBjb250YWluIGFsbCBM U1AgcGFyYW1ldGVycyB0aGF0IGEgUENFIHdpc2hlcyB0byBzZXQgZm9yIHRoZSBMU1AuIEEgUEND IE1BWSBzZXQgbWlzc2luZyBwYXJhbWV0ZXJzIGZyb20gbG9jYWxseSBjb25maWd1cmVkIGRlZmF1 bHRzLg0KDQojIyMgVGhhbmtzIGZvciBjYXRjaGluZyENCg0KQ29tbWVudHM6IElmIGEgUENDIE1V U1QgcmVjZWl2ZSBhbGwgdGhlIExTUCBwYXJhbWV0ZXJzIGZyb20gdGhlIExTUCBVcGRhdGUgUmVx dWVzdCBzZW5kIGZyb20gYW4gYWN0aXZlIHN0YXRlZnVsIFBDRSwgd2h5IHRoZSBzZWNvbmQgc2Vu dGVuY2UgaXMgcmVxdWlyZWQ/DQoNCiMjIyBCZWNhdXNlIHRoZSBQQ0UgbWF5IHdpc2ggdG8gb25s eSB1cGRhdGUgYmFuZHdpZHRoIGZvciBleGFtcGxlLCBzbyBldmVyeXRoaW5nIGVsc2UgKGUuZy4g cHJpb3JpdGllcyApIHdpbGwgYmUgc2V0IGZyb20gbG9jYWxseSBjb25maWd1cmVkIGRlZmF1bHRz Lg0KPlhpYW46IE9rYXksIG5vdyBJIGdldCBpdDsgSSBwcm9iYWJseSBoYXZlIGJlZW4gY29uZnVz ZWQgdGhlIHdvcmQgobBhbGyhsSBpbmNsdWRlZCBpbiB0aGUgZmlyc3Qgc2VudGVuY2UsIHdoaWNo IGFjdHVhbGx5IGRlbm90ZXMgb25lIG9yIGEgc3Vic2V0IG9mIHBhcmFtZXRlcnMuDQoNClNlY3Rp b24gNy4xOg0KU2luY2UgbXVsdGlwbGUgVExWcyBhcmUgZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24s IEkgc3VnZ2VzdCBtb3ZpbmcgdGhlIG9ubHkgc2VudGVuY2UgZGlyZWN0bHkgdW5kZXIgdGhpcyBz ZWN0aW9uIHRvIFNlY3Rpb24gNy4xLjEuIFRoZSBmb2xsb3dpbmcgaXMgdGhlIHN1Z2dlc3RlZCB0 ZXh0ICh0byByZXBsYWNlIHRoZSBmaXJzdCBwYXJhZ3JhcGggdW5kZXIgU2VjdGlvbiA3LjEuMSk6 DQpTdGF0ZWZ1bCBQQ0UgQ2FwYWJpbGl0eSBUTFYgaXMgYW4gb3B0aW9uYWwgVExWIGZvciB0aGUg T1BFTiBPYmplY3QgdG8gc3VwcG9ydCBzdGF0ZWZ1bCBQQ0UgY2FwYWJpbGl0eSBuZWdvdGlhdGlv bi4gVGhlIGZvcm1hdCBvZiB0aGlzIG5ldyBUTFYgaXMgc2hvd24gaW4gdGhlIGZvbGxvd2luZyBm aWd1cmUuDQoNCiMjIyBUaGFuayB5b3UgZm9yIGNhdGNoaW5nDQoNClNlY3Rpb24gNy4xLjEuOg0K T2xkOiBpZiBzZXQgdG8gMSBieSBhIFBDRSwgdGhlIFUgRmxhZyBpbmRpY2F0ZXMgdGhhdCB0aGUg UENFIHdpc2hlcyB0byB1cGRhdGUgTFNQIHBhcmFtZXRlcnMuDQpOZXc6IGlmIHNldCB0byAxIGJ5 IGEgUENFLCB0aGUgVSBGbGFnIGluZGljYXRlcyB0aGF0IHRoZSBQQ0UgaXMgY2FwYWJsZSBvZiB1 cGRhdGluZyBMU1AgcGFyYW1ldGVycy4NCg0KIyMjIFdpbGwgYWRkIHRvIHZlcnNpb24gMDQuDQoN ClF1ZXN0aW9uc6O6DQoxOiBJIGFtIHRyeWluZyB0byBnZXQgYSBiZXR0ZXIgdW5kZXJzdGFuZGlu ZyBvZiBMU1AgZGVsZWdhdGlvbiBhbmQgaXRzIHByb2Nlc3MuIEZyb20gRmlndXJlIDEzLCBTdGVw IE9uZSAoTFNQIHN0YXRlIHN5bmNocm9uaXphdGlvbiBvciBhZGQgbmV3IExTUCksIGRvIHlvdSBt ZWFuIHRoYXQgd2hlbiBhIFBDQyBnZXQgYSBzZXJ2aWNlIHJlcXVlc3QsIGl0IG9ubHkoIGFuZCBo YXZlIHRvKSB3aWxsIGFzc2lnbiBhIDIwLWJpdCBMU1AgaWRlbnRpZmllciAocHJvYmFibHkgdGhl IExTUCBpZGVudGlmaWVyIFRMViBhcyB3ZWxsPyksIGFuZCB0aGVuIGRlbGVnYXRlIGl0IHRvIFBD RSBmb3Igcm91dGUgc2VsZWN0aW9uIGV0Yy4/IElmIHNvLCBpdCBsb29rcyB0byBtZSBhIGJpdCBs aWtlIHJlcGxhY2luZyBQQ1JlcSBtZXNzYWdlIGZ1bmN0aW9uIGhlcmUuIElmIEkgYW0gd3Jvbmcs IHBsZWFzZSBjb3JyZWN0IG1lLg0KDQojIyMgVGhlIG1vbWVudCB5b3UgZGVsZWdhdGUsIHlvdSBo YXZlIHRvIGFzc2lnbiB0aGUgaWRlbnRpZmllci4gTm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSCh sHJlcGxhY2luZyBQY3JlcaGxLg0KPlhpYW46ICBNeSBxdWVzdGlvbiBhcmlzZXMgZnJvbSB0aGUg ZmlndXJlLiBJbiBTdGVwIE9uZSAoTFNQIHN0YXRlIHN5bmNocm9uaXphdGlvbiBvciBhZGQgbmV3 IExTUCkuIEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggZm9ybWVyIHBhcnQuIEJ1dCB3aGVuIGl0IGlz IKGwYWRkIG5ldyBMU1ChsSAodGhlIDJuZCBoYWxmKSwgaXQgc2VuZHMgUENScHQgd2l0aCBEPTEu IFNvIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIG5ldyBMU1AgZG9lcyBub3QgZXZlbiBM U1AgaW5mby4gYXQgYWxsIChzdWNoIGFzIGJhbmR3aWR0aCwgcm91dGUgZXRjLikgd2hlbiBpdCBp cyBkZWxlZ2F0ZWQgdG8gUENFLiBJcyB0aGlzIHRoZSBpbnRlbnRpb24/IElmIHNvLCBpdCBpcyBy ZXBsYWNpbmcgUENSZXEgKHNpbmNlIHdpdGggc3RhdGVsZXNzIFBDRSwgYSBQQ0Mgc2VuZHMgYSBQ Q1JlcSBtc2cgZmlyc3Qgd2hlbiBpdCByZWNlaXZlcyBhIHJlcXVlc3QgdG8gc2V0IHVwIG5ldyBM U1ApLg0KDQoyOiBJbiB0aGUgUkJORiBkZWZpbml0aW9uIG9mIFBDUnB0IG1lc3NhZ2UsIDxzdGF0 ZS1yZXBvcnQ+IDo6PSA8TFNQPiBbPHBhdGgtbGlzdD5dLiBCdXQgZm9yIGEgZ2l2ZW4gTFNQIGlk ZW50aWZpZWQgYnkgdGhlIDIwIGJpdCBMU1AgSUQsIGl0IG1hdGNoZXMgdGhlIDxzb3VyY2UgYWRk ciwgZGVzdGluYXRpb24gYWRkcmVzcywgdHVubmVsIElELCBMU1AgSUQ+IGlkZW50aWZpZXIuIFRo ZW4sIGl0IHNob3VsZCBoYXZlIG9uZSA8cGF0aD4gZGVzY3JpcHRvciBub3QgbGlzdC4gSSB3b25k ZXIgd2hldGhlciB0aGVyZSBpcyBhbnkgbWlzdW5kZXJzdGFuZGluZyBvZiB0aGUgY29uY2VwdCBo ZXJlPw0KDQojIyMgVGhlcmUgbmVlZHMgdG8gYmUgY2xlYW51cCBpbiBzZXZlcmFsIHBsYWNlcyBp biB0aGUgZG9jLg0KPlhpYW46IEkgZGlkIG5vdCBmaW5kIHVwZGF0ZSByZWxhdGluZyB0byB0aGlz IGVucXVpcnkgaW4gVjQuIENvdWxkIHlvdSBwb2ludCB0byBtZSB3aGVyZSBpbiBWZXJzaW9uIDQg YWRkcmVzcyB0aGUgYWJvdmUgaXNzdWU/DQoNCjM6IElmIGEgUlNWUCAxNi1iaXQgTFNQIElEIGNo YW5nZSwgd2lsbCB0aGUgMjAtYml0IExTUCBJRCBjaGFuZ2U/IEl0IGlzIG5vdCBleHBsYWluZWQg aW4gdGhpcyBkcmFmdC4gSSBzdWdnZXN0IGFkZGluZyBzb21lIHNvcnQgb2YgZXhwbGFuYXRpb24g c2luY2UgaXQgaXMgaW1wb3J0YW50IGluIGNhc2VzIHN1Y2ggYXMgcmUtb3B0aW1pemF0aW9uL3Jl LXJvdXRpbmcuDQoNCiMjIyBObywgdGhlIGludGVudCB3YXMgZm9yIHRoZSBQTFNQLWlkIG5vdCB0 byBjaGFuZ2UuIFdpbGwgZXZhbHVhdGUgYSBjbGFyaWZpY2F0aW9uIGZvciB2ZXJzaW9uIDA0Lg0K PlhpYW46IE9rYXk7IHNvIGRvIHlvdSBtZWFuIGEgMjAtYml0IFBMU1AtSUQgd2lsbCBoYXZlIG11 bHRpcGxlIDxzb3VyY2UgYWRkciwgZGVzdGluYXRpb24gYWRkcmVzcywgdHVubmVsIElELCBMU1Ag SUQgPiBpZGVudGlmaWVycyBsaW5rZWQgdG8gaXQgKGEuay5hLiBvbmUgUExTUC1JRCBlcXVhbHMg dG8gbXVsdGlwbGUgTFNQIGluIFJTVlAtVEUgY29udGV4dCk/IENvdWxkIHlvdSBwb2ludCBvdXQg dGhlIGNsYXJpZmljYXRpb24geW91IG1lbnRpb25lZD8gVGhhbmsgeW91Lg0KDQoNCkJlc3QgUmVn YXJkcywNCg0KTWlzcyBYaWFuIFpIQU5HIChQaC5ELikNCg0KUmVzZWFyY2ggRW5naW5lZXINClRy YW5zbWlzc2lvbiBUZWNobm9sb2d5IFJlc2VhcmNoIERlcHQuDQpOZXR3b3JrIFByb2R1Y3QgTGlu ZQ0KUmVzZWFyY2ggQXJlYSBGMy01LCBIdWF3ZWkgSW5kdXN0cmlhbCBCYXNlLCBCYW50aWFuLCBM b25nZ2FuZyBEaXN0cmljdCwgU2hlbnpoZW4uDQo1MTgxMjkgLCBQLlIuQy4NClRlbKO6Kzg2IDA3 NTUgMjg5NzI5MTMNCg0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e 09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfvWucjOus7G5Mv7yMvS1MjOus7Q zsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPK vP7W0LXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8 /sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFi b3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3 YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Ns b3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp dmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9u ZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQo= --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BF3B2szxeml510mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Ina= ,

&n= bsp;

= Thank you for your reply and update on the draft. Please see my further com= ments on some of the points inline, starting with =A1=B0>Xian:=A1=B1.

&n= bsp;

= I have additional comments on Version 4, will send them out in a separate e= mail soon.

&n= bsp;

Regards= ,

Xian

&n= bsp;

PS:&nbs= p; I have added the PCE WG mailing list for the benefit of the working grou= p.

&n= bsp;

From: Ina Minei [m= ailto:ina@juniper.net]
Sent: 2013=C4=EA4=D4=C23=C8= =D5 4:04
To: Zhangxian (Xian); draft-ietf-pce-stateful-pce@tools.ietf.org
Cc: Fatai Zhang; Leeyoung
Subject: RE: Xian's comments on draft-ietf-pce-stateful-pce

Xian,

Apologies for the delay in reply, please see responses inline bel= ow, look for ###.

From: Zhangxian (X= ian) [mailto:zhang.xian@huawei.com]
Sent: Wednesday, February 20, 2013 10:57 PM
To: draft-ietf-pce-stateful-pce@tools.ietf.org
Cc: Fatai Zhang; Leeyoung
Subject:

Hi, Dear all,

As promised during= last IETF meeting, I have reviewed this draft. The following is my detaile= d suggestions with provided text for improving the draft as well as a coupl= e of questions I am looking forward to hear from you.

*Suggestions/Comments:

Section 3.2:<= /p>

o Allow a PCE to specify = protection / restoration settings for all LSPs that have been delegated to = it.

Comment: This may be, indeed, a= requirement for stateful PCEP extension, but it is not covered in this doc= ument as pointed out later in the document. Alternatively, this section can= be re-written a bit to make the Objective not confined to this document.

&n= bsp;

### Yes, good point, will update in the next revision.=

Section 5.2:<= /p>

Since in Section 4, it is clear= ly stated that stateful capabilities discovery is not in the scope of this = document, I would recommend to remove the last two rows of the table presen= ted in this section. Moreover, add a reference to the document which defines so would also be helpful.

### The reference to the discovery draft was added in version 03 = in section 4, so I think it is ok to leave the last 2 lines.

Section 5.3:<= /p>

Old: LSP delegation and LSP upd= ate operations defined in this document MAY only be used if both PCEP Speak= ers set the LSP-UPDATE Flag in the "Stateful Capability" TLV to '= Updates Allowed (U Flag =3D 1)', otherwise a PCErr with code "Delegation not negotiated" (see Section 8.4) will be = generated.

New: LSP delegation and LSP upd= ate operations defined in this document MUST only be used if both PCEP Spea= kers set the LSP-UPDATE-CAPABILITY Flag in the "Stateful PCE Capabilit= y" TLV to 'Updates Allowed (U Flag =3D 1)', otherwise a PCErr with code "Delegation not negotiated" (see Sec= tion 8.4) will be generated.

Comment: From Section 7.1.1, th= e requirement is a MUST not a MAY?

### I don=A1=AFt agree, here is an explanation. Section 7.1.1 say= s the capability MUST be advertised by both ends. The extensions MAY be use= d, not MUST be used. Basically, you can negotiate the capability and then don=A1=AFt do any delegation or update, and that i= s ok. If you want to use them, you can, but only if you did the negotiation= . So I think it should be MAY.

>Xia= n: I agree with what you explained above; but here, I thought it is talking= about how to handle error situation. My interpretation of this sentence is= that it intends to limit the situation when the LSP delegation and LSP update operations MUST be followed (when it is = enabled, of course). Then, the rule is not followed, for example, if LSP up= date operation is used without U=3D1, then error should be reported. Is tha= t what you intend to say?

Section 5.4.1=A3=BA=

Old=A3=BAIf a PCC's LSP State = Database survived the restart, the PCC will include the LSP-DB-VERSION TLV = in its OPEN object and the TLV will contain the last LSP State Database version sent on an LSP State Update from the PCC in the pre= vious PCEP session.

New=A3=BAIf a PCC's LSP State = Database survived the restart, the PCC will include the LSP-DB-VERSION TLV = in its OPEN object and the TLV will contain the LSP State Database version included in its last LSP State Report sent in the previou= s PCEP session.

### There was a terminology change from lsp state update to lsp s= tate report in one of the very early versions of this draft, and the text s= till had a few old references. I have fixed them all now, thank you for pointing them out.

Old: Note that the same State S= ynchronization sequence would happen if either the PCE or the PCE would not= include the LSP-DB-VERSION TLV in their respective Open messages.

New: Note that the same State S= ynchronization sequence would happen if either the PCE or the PCC would not= include the LSP-DB-VERSION TLV in their respective Open messages.

### fixed in version 03

Figure 8: the =A1=B0LSP State U= pdate=A1=B1 should be changed to =A1=B0LSP State Report=A1=B1.

&n= bsp;

### Thanks for catching, see the explanation above.

Section 5.5:<= /p>

LSPs are delegated individually= - different LSPs may be delegated to different PCEs, and an LSP may be del= egated to one or more PCEs.

Comment: To avoid confusion and= link this back to Section 3.2, I would suggest to add the following senten= ce:

However, a LSP is under control= of a single PCE at any given time.

### The text is clarified in version 03.

Section 5.5.1:

Old: Delegation acceptance is c= onfirmed when the PCC wishes to update the LSP via the LSP Update Request.&= nbsp; If a PCE does not accept the LSP Delegation, it MUST immediately resp= ond with an empty LSP Update Request which has the Delegate flag set to 0.

New: Delegation acceptance is c= onfirmed when the PCE sends the first LSP Update Request with Delegate flag set to 1= . If a PCE does not accept the LSP Delegation, it MUST immediately resp= ond with an empty LSP Update Request which has the Delegate flag set to 0.<= o:p>

### The text is clarified in version 03.

>Xia= n: I checked Version 4, it does not fully catches my comment. The delegatio= n acceptance can only be confirmed with receiving messages sent from PCE, n= ot when PCE wishes to update via the LSP Update Request. Maybe, I am being picky. So you do not have to follow my s= uggestion, but at least do not use the word =A1=B0wish=A1=B1, J= .

&n= bsp;

Section 6.2=A3=BA=

Old: An LSP Update Request MUST= contain all LSP parameters that a PCC wishes to set for the LSP. A PCC MAY= set missing parameters from locally configured defaults.=

New: An LSP Update Request MUST= contain all LSP parameters that a PCE wishes to set for the LSP. A PCC MAY= set missing parameters from locally configured defaults.=

### Thanks for catching!

Comments: If a PCC MUST receive= all the LSP parameters from the LSP Update Request send from an active sta= teful PCE, why the second sentence is required?

### Because the PCE may wish to only update bandwidth for example= , so everything else (e.g. priorities ) will be set from locally configured= defaults.

>Xia= n: Okay, now I get it; I probably have been confused the word =A1=B0all=A1= =B1 included in the first sentence, which actually denotes one or a subset = of parameters.

Section 7.1:<= /p>

Since multiple TLVs are defined= in this section, I suggest moving the only sentence directly under this se= ction to Section 7.1.1. The following is the suggested text (to replace the= first paragraph under Section 7.1.1):

Stateful PCE Capability TLV is = an optional TLV for the OPEN Object to support stateful PCE capability nego= tiation. The format of this new TLV is shown in the following figure.<= /o:p>

### Thank you for catching

Section 7.1.1.:

Old: if set to 1 by a PCE, the = U Flag indicates that the PCE wishes to update LSP parameters.

New: if set to 1 by a PCE, the = U Flag indicates that the PCE is capable of updating LSP parameters.

### Will add to version 04.

Questions=A3=BA

1: I am trying to get a better = understanding of LSP delegation and its process. From Figure 13, Step One (= LSP state synchronization or add new LSP), do you mean that when a PCC get = a service request, it only( and have to) will assign a 20-bit LSP identifier (probably the LSP identifier TLV a= s well?), and then delegate it to PCE for route selection etc.? If so, it l= ooks to me a bit like replacing PCReq message function here. If I am wrong,= please correct me.

### The moment you delegate, you have to assign the identifier. N= ot sure what you mean by =A1=B0replacing Pcreq=A1=B1.

>Xia= n: My question arises from the figure. In Step One (LSP state synchro= nization or add new LSP). I have no problem with former part. But when it i= s =A1=B0add new LSP=A1=B1 (the 2^nd half), it sends PCRpt with D=3D1. So my understanding is that this new LSP does not = even LSP info. at all (such as bandwidth, route etc.) when it is delegated = to PCE. Is this the intention? If so, it is replacing PCReq (since with sta= teless PCE, a PCC sends a PCReq msg first when it receives a request to set up new LSP).

2: In the RBNF definition of PC= Rpt message, <state-report> ::=3D <LSP> [<path-list>]. Bu= t for a given LSP identified by the 20 bit LSP ID, it matches the <sourc= e addr, destination address, tunnel ID, LSP ID> identifier. Then, it should have one <path> descriptor not list. I wonder whethe= r there is any misunderstanding of the concept here?

### There needs to be cleanup in several places in the doc.

>Xia= n: I did not find update relating to this enquiry in V4. Could you point to= me where in Version 4 address the above issue?

&n= bsp;

3: If a RSVP 16-bit LSP ID chan= ge, will the 20-bit LSP ID change? It is not explained in this draft. I sug= gest adding some sort of explanation since it is important in cases such as= re-optimization/re-routing.

### No, the intent was for the PLSP-id not to change. Will evalua= te a clarification for version 04.

>Xia= n: Okay; so do you mean a 20-bit PLSP-ID will have multiple <source addr= , destination address, tunnel ID, LSP ID > identifiers linked to it (a.k= .a. one PLSP-ID equals to multiple LSP in RSVP-TE context)? Could you point out the clarification you mentioned? Thank you. =

Best Re= gards,

&n= bsp;

Miss Xi= an ZHANG (Ph.D.)

&n= bsp;

Researc= h Engineer

Transmi= ssion Technology Research Dept.

Network= Product Line

Researc= h Area F3-5, Huawei Industrial Base, Bantian, Longgang District, Shenzhen.<= o:p>

518129 = , P.R.C.

Tel=A3=BA+86 0755 28972913

&n= bsp;

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9= =AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD= =B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8= =BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE= =D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2= =BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2= =B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4= =FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7= =BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1= =BE=D3=CA=BC=FE=A3=A1

This= e-mail and its attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but not limited to, total or partial disclos= ure, reproduction, or dissemination) by persons other than the intended rec= ipient(s) is prohibited. If you receive this e-mail in error, please notify= the sender by phone or email immediately and delete it!

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B189BF3B2szxeml510mbxchi_-- From internet-drafts@ietf.org Mon Jun 10 10:00:07 2013 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 008BF21F9947; Mon, 10 Jun 2013 10:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHgbvvYxWNqe; Mon, 10 Jun 2013 10:00:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D62E321F8EF2; Mon, 10 Jun 2013 10:00:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130610170005.14320.89339.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2013 10:00:05 -0700 Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-gmpls-aps-req-08.txt 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, 10 Jun 2013 17:00:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Path Computation Element Working Group of= the IETF. Title : Requirements for GMPLS applications of PCE Author(s) : Tomohiro Otani Kenichi Ogaki Diego Caviglia Fatai Zhang Cyril Margaria Filename : draft-ietf-pce-gmpls-aps-req-08.txt Pages : 12 Date : 2013-06-10 Abstract: The initial effort of the PCE (Path computation element) WG is specifically focused on MPLS. As a next step, this draft describes functional requirements for GMPLS application of PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-aps-req-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pce-gmpls-aps-req-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ke-oogaki@kddi.com Mon Jun 10 10:13:16 2013 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 3157E21F9649 for ; Mon, 10 Jun 2013 10:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8zA3Z78S48W for ; Mon, 10 Jun 2013 10:13:12 -0700 (PDT) Received: from UTMC1102.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3213421F9648 for ; Mon, 10 Jun 2013 10:13:11 -0700 (PDT) Received: from UTMC1135 (unknown [10.5.16.204]) by UTMC1102.kddi.com (Postfix) with SMTP id 43C932D63; Tue, 11 Jun 2013 02:13:10 +0900 (JST) Received: from UTMC1124.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id CE3D61C44; Tue, 11 Jun 2013 02:13:05 +0900 (JST) Received: from LTMC1005.kddi.com (unknown [10.5.16.216]) by UTMC1124.kddi.com (Postfix) with ESMTP id B23BF1C2A; Tue, 11 Jun 2013 02:13:05 +0900 (JST) Received: from LTMC1005.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r5AHD54s004946; Tue, 11 Jun 2013 02:13:05 +0900 Received: from LTMC1005.kddi.com.mid_18610915 (localhost.localdomain [127.0.0.1]) by LTMC1005.kddi.com with ESMTP id r5AH31p0003212; Tue, 11 Jun 2013 02:03:01 +0900 Received: by post-zip.kddi.com; Tue, 11 Jun 2013 02:03:00 +0900 Message-id: In-Reply-To: <20130610170005.14320.89339.idtracker@ietfa.amsl.com> References: <20130610170005.14320.89339.idtracker@ietfa.amsl.com> Date: Tue, 11 Jun 2013 02:03:00 +0900 From: "Kenichi Ogaki" To: pce@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SA-MID: 18610915 X-WAuditID: 1306110213050000514451 Subject: Re: [Pce] I-D Action: draft-ietf-pce-gmpls-aps-req-08.txt 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, 10 Jun 2013 17:13:16 -0000 Dear PCErs, We uploaded the revised draft which addressed all the comments in IETF last call as follows. https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=69807&tid=1370830337 http://www.ietf.org/mail-archive/web/pce/current/msg03141.html Thanks, Kenichi & co-authors >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Path Computation Element Working Group of the IETF. > > Title : Requirements for GMPLS applications of PCE > Author(s) : Tomohiro Otani > Kenichi Ogaki > Diego Caviglia > Fatai Zhang > Cyril Margaria > Filename : draft-ietf-pce-gmpls-aps-req-08.txt > Pages : 12 > Date : 2013-06-10 > >Abstract: > The initial effort of the PCE (Path computation element) WG is > specifically focused on MPLS. As a next step, this draft describes > functional requirements for GMPLS application of PCE. > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pce-gmpls-aps-req-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-aps-req-08 > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce -- Kenichi Ogaki KDDI Corp. | IP Transport Network Development Dept. +81-(0)80-5945-9138 | www.kddi.com From julien.meuric@orange.com Tue Jun 11 01:25:53 2013 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 E0DFB21F8ECB for ; Tue, 11 Jun 2013 01:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9kuKHCPGaQJ for ; Tue, 11 Jun 2013 01:25:47 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 881DD21F8DE4 for ; Tue, 11 Jun 2013 01:25:46 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 360E0410261 for ; Tue, 11 Jun 2013 10:25:45 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 2F8BF41021E for ; Tue, 11 Jun 2013 10:25:45 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jun 2013 10:25:45 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jun 2013 10:25:44 +0200 Message-ID: <51B6DF08.3000407@orange.com> Date: Tue, 11 Jun 2013 10:25:44 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pce@ietf.org" References: <519B3383.10604@orange.com> In-Reply-To: <519B3383.10604@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Jun 2013 08:25:44.0793 (UTC) FILETIME=[4495B490:01CE667D] Subject: Re: [Pce] WG Last Call of draft-ietf-pce-pcep-inter-domain-p2mp-procedures 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: Tue, 11 Jun 2013 08:25:53 -0000 Hi PCE WG. This last call ended last week, but I have not seen much comment from reviewers. You might still get a chance before IETF last call... Chairs' review will be sent soon. Regards, Julien Le 21/05/2013 10:42, Julien Meuric a �crit : > Hi all. > > This message ignites a two-week period to collect feedback on > draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04. Please send your > comments on the document to the PCE mailing list by Tuesday June 4, > noon UTC. > > Regards, > > JP & Julien From julien.meuric@orange.com Wed Jun 12 01:08:59 2013 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 9298321F9C11 for ; Wed, 12 Jun 2013 01:08:59 -0700 (PDT) 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=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyAZQheMrdqF for ; Wed, 12 Jun 2013 01:08:52 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4132F21F9C0B for ; Wed, 12 Jun 2013 01:08:52 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F976410261 for ; Wed, 12 Jun 2013 10:08:50 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 9B00841025D for ; Wed, 12 Jun 2013 10:08:50 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jun 2013 10:08:48 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jun 2013 10:08:50 +0200 Message-ID: <51B82C91.3050304@orange.com> Date: Wed, 12 Jun 2013 10:08:49 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2013 08:08:50.0238 (UTC) FILETIME=[1246A5E0:01CE6744] Subject: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10 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: Wed, 12 Jun 2013 08:08:59 -0000 Hi PCE'rs. This message ignites a 2-week-long WG last call for draft-ietf-pce-vendor-constraints-10. Please send your comments on the I-D to the PCE mailing list by Wednesday June 26. Best regards, JP & Julien From adrian@olddog.co.uk Wed Jun 12 07:27:43 2013 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 F402321F9B96 for ; Wed, 12 Jun 2013 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbwGuDB1vgEq for ; Wed, 12 Jun 2013 07:27:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 3059221F9BAF for ; Wed, 12 Jun 2013 07:27:12 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5CERAsV020179; Wed, 12 Jun 2013 15:27:10 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5CER9KJ020149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 15:27:09 +0100 From: "Adrian Farrel" To: , Date: Wed, 12 Jun 2013 15:27:04 +0100 Message-ID: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5neOV6bpyH43/bTpiBxi1xkaK/TA== Content-Language: en-gb Subject: [Pce] Next steps for draft-farrkingel-pce-questions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:27:44 -0000 Hi chairs and working group, Dan and I are wondering what to do with this draft. It seems that a number of people have been reading it and have found it useful or at least stimulating. At the moment, it represents just the rambling thoughts of two individuals, so my question is really whether the WG thinks this would be something that could be usefully published as an RFC or should be judged to have served its purpose now and allowed to die. If published as an RFC there would be a number of ways to go forward: adoption by the WG and subsequent edits; publication of the individual I-D under the care of the WG (still review and edit, but faster); publication as an individual I-D (under the care of an AD with review by the PCE working group). We'd be interested to know what you think before we decide what action to request for the document. And, of course, any issues or thoughts on the document would be very welcome. Thanks, Adrian From ramon.casellas@cttc.es Wed Jun 12 07:36:02 2013 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 E904321F9ADE for ; Wed, 12 Jun 2013 07:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulbDtNgEb0Xa for ; Wed, 12 Jun 2013 07:36:02 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42921F9AD3 for ; Wed, 12 Jun 2013 07:36:02 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Umm9Y-0004uO-AQ for pce@ietf.org; Wed, 12 Jun 2013 16:36:00 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id DC4A61FE22 for ; Wed, 12 Jun 2013 16:35:51 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <51B88746.8000603@cttc.es> Date: Wed, 12 Jun 2013 16:35:50 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pce@ietf.org References: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> In-Reply-To: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spamina-Bogosity: Ham Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions 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: Wed, 12 Jun 2013 14:36:03 -0000 El 12/06/2013 16:27, Adrian Farrel escribi�: > At the moment, it represents just the rambling thoughts of two individuals, so > my question is really whether the WG thinks this would be something that could > be usefully published as an RFC or should be judged to have served its purpose > now and allowed to die. > Dear Adrian, all, Just thinking out loud, I don't have (yet) an opinion on this ... I find the draft useful, and I wouldn't want it to dissapear but, on the other hand, I also think of it as of something "alive" and which could, potentially, be updated more-or-less "regularly" depending on the working group progress. What would be in this case the best way to proceed? refresh it as I-D -01,02,03... "ad infinitum", publish as RFC and then submit -bis -ter if need be, or update it via RFC errata? thanks, R. From adrian@olddog.co.uk Thu Jun 13 09:45:37 2013 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 5613221F962D for ; Thu, 13 Jun 2013 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOxyBrnSqE6r for ; Thu, 13 Jun 2013 09:45:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2989421F9633 for ; Thu, 13 Jun 2013 09:45:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5DGjSrk022585; Thu, 13 Jun 2013 17:45:28 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5DGjRm5022574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jun 2013 17:45:27 +0100 From: "Adrian Farrel" To: "'Ramon Casellas'" References: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> <51B88746.8000603@cttc.es> In-Reply-To: <51B88746.8000603@cttc.es> Date: Thu, 13 Jun 2013 17:45:26 +0100 Message-ID: <01ae01ce6855$689a3ad0$39ceb070$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHV13HthpvY4gzwFcQ+I+uZ3WiMnwEvxxT+mRt8AmA= Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:45:37 -0000 Hi Ramon, > > At the moment, it represents just the rambling thoughts of two individuals, so > > my question is really whether the WG thinks this would be something that > > could be usefully published as an RFC or should be judged to have served > > its purpose now and allowed to die. > > Just thinking out loud, I don't have (yet) an opinion on this ... I find > the draft useful, and I wouldn't want it to dissapear but, on the other > hand, I also think of it as of something "alive" and which could, > potentially, be updated more-or-less "regularly" depending on the > working group progress. What would be in this case the best way to > proceed? refresh it as I-D -01,02,03... "ad infinitum", publish as RFC > and then submit -bis -ter if need be, or update it via RFC errata? I suppose the question might be: Could we get to a position where we have covered 90% of the questions that might arise in subsequent two years? If so, then it would sound like an RFC might be useful. Just like we published the original framework RFC without keeping it alive for ever as a regularly-updated I-D. But if we don't think we can get this stable (perhaps the field is expanding too fast) then maybe a wiki? I don't like a wiki for this because it doesn't register consensus or become more widely visible. Cheers, Adrian From zhangfatai@huawei.com Thu Jun 13 20:13:41 2013 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 93E0511E80CC for ; Thu, 13 Jun 2013 20:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2PBISH++6CG for ; Thu, 13 Jun 2013 20:13:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D6CBD21E8055 for ; Thu, 13 Jun 2013 20:13:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASL08330; Fri, 14 Jun 2013 03:13:32 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 14 Jun 2013 04:13:10 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 14 Jun 2013 11:13:26 +0800 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.94]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Fri, 14 Jun 2013 11:13:17 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , "'Ramon Casellas'" Thread-Topic: [Pce] Next steps for draft-farrkingel-pce-questions Thread-Index: Ac5neOV6bpyH43/bTpiBxi1xkaK/TP//fF0AgAG2igD//ss1gA== Date: Fri, 14 Jun 2013 03:13:11 +0000 Message-ID: References: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> <51B88746.8000603@cttc.es> <01ae01ce6855$689a3ad0$39ceb070$@olddog.co.uk> In-Reply-To: <01ae01ce6855$689a3ad0$39ceb070$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions 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, 14 Jun 2013 03:13:41 -0000 Hi Adrian, I prefer an informational RFC, where people can get much valuable informati= on by reading this document quickly.=20 Best Regards Fatai -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adria= n Farrel Sent: Friday, June 14, 2013 12:45 AM To: 'Ramon Casellas' Cc: pce@ietf.org Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions Hi Ramon, > > At the moment, it represents just the rambling thoughts of two individu= als, so > > my question is really whether the WG thinks this would be something tha= t > > could be usefully published as an RFC or should be judged to have serve= d > > its purpose now and allowed to die. >=20 > Just thinking out loud, I don't have (yet) an opinion on this ... I find > the draft useful, and I wouldn't want it to dissapear but, on the other > hand, I also think of it as of something "alive" and which could, > potentially, be updated more-or-less "regularly" depending on the > working group progress. What would be in this case the best way to > proceed? refresh it as I-D -01,02,03... "ad infinitum", publish as RFC > and then submit -bis -ter if need be, or update it via RFC errata? I suppose the question might be: Could we get to a position where we have covered 90% of the questions that = might arise in subsequent two years? If so, then it would sound like an RFC might be useful. Just like we publis= hed the original framework RFC without keeping it alive for ever as a regularly-updated I-D. But if we don't think we can get this stable (perhaps the field is expandin= g too fast) then maybe a wiki?=20 I don't like a wiki for this because it doesn't register consensus or becom= e more widely visible. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ina@juniper.net Fri Jun 14 14:19:30 2013 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 7B86B21F9B8D for ; Fri, 14 Jun 2013 14:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.605 X-Spam-Level: ** X-Spam-Status: No, score=2.605 tagged_above=-999 required=5 tests=[AWL=6.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt3QjhxVSZ32 for ; Fri, 14 Jun 2013 14:19:24 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 308C821F9AE2 for ; Fri, 14 Jun 2013 14:19:19 -0700 (PDT) Received: from mail40-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE010.bigfish.com (10.236.130.73) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 21:19:12 +0000 Received: from mail40-co9 (localhost [127.0.0.1]) by mail40-co9-R.bigfish.com (Postfix) with ESMTP id 0AE13100610 for ; Fri, 14 Jun 2013 21:19:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail40-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=ina@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail40-co9 (localhost.localdomain [127.0.0.1]) by mail40-co9 (MessageSwitch) id 137124474825861_21253; Fri, 14 Jun 2013 21:19:08 +0000 (UTC) Received: from CO9EHSMHS021.bigfish.com (unknown [10.236.132.237]) by mail40-co9.bigfish.com (Postfix) with ESMTP id E56227C0052 for ; Fri, 14 Jun 2013 21:19:07 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS021.bigfish.com (10.236.130.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Jun 2013 21:19:07 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 14 Jun 2013 14:19:06 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 14 Jun 2013 14:19:05 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.253) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 14 Jun 2013 14:30:34 -0700 Received: from mail19-db9-R.bigfish.com (10.174.16.247) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 21:19:03 +0000 Received: from mail19-db9 (localhost [127.0.0.1]) by mail19-db9-R.bigfish.com (Postfix) with ESMTP id CB7FB60233 for ; Fri, 14 Jun 2013 21:19:03 +0000 (UTC) Received: from mail19-db9 (localhost.localdomain [127.0.0.1]) by mail19-db9 (MessageSwitch) id 1371244736279097_9993; Fri, 14 Jun 2013 21:18:56 +0000 (UTC) Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.252]) by mail19-db9.bigfish.com (Postfix) with ESMTP id 25449480046; Fri, 14 Jun 2013 21:18:56 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Jun 2013 21:18:52 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0324.000; Fri, 14 Jun 2013 21:18:47 +0000 From: Ina Minei To: "adrian@olddog.co.uk" , 'Ramon Casellas' , Fatai Zhang Thread-Topic: [Pce] Next steps for draft-farrkingel-pce-questions Thread-Index: Ac5neOV6bpyH43/bTpiBxi1xkaK/TAAATzYAADbRUgAAO4nA4A== Date: Fri, 14 Jun 2013 21:18:46 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037EF28C@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> <51B88746.8000603@cttc.es> <01ae01ce6855$689a3ad0$39ceb070$@olddog.co.uk> In-Reply-To: <01ae01ce6855$689a3ad0$39ceb070$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CTTC.ES$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "pce@ietf.org" Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions 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, 14 Jun 2013 21:19:30 -0000 Adrian,=20 I think there is value in this document, and it seems to fit well with an i= nformational document. While I share your concern that some areas are rapid= ly changing, the process of progressing documents is not very fast either, = so there is time and opportunity to update it :-) Ina =20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adria= n Farrel Sent: Thursday, June 13, 2013 9:45 AM To: 'Ramon Casellas' Cc: pce@ietf.org Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions [snip] I suppose the question might be: Could we get to a position where we have covered 90% of the questions that = might arise in subsequent two years? If so, then it would sound like an RFC might be useful. Just like we publis= hed the original framework RFC without keeping it alive for ever as a regul= arly-updated I-D. But if we don't think we can get this stable (perhaps the field is expandin= g too fast) then maybe a wiki?=20 I don't like a wiki for this because it doesn't register consensus or becom= e more widely visible. Cheers, Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From leeyoung@huawei.com Fri Jun 14 14:36:10 2013 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 33DF321F9AF1 for ; Fri, 14 Jun 2013 14:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFoQOdWS5A7o for ; Fri, 14 Jun 2013 14:36:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBB121F9ADA for ; Fri, 14 Jun 2013 14:36:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASL78390; Fri, 14 Jun 2013 21:36:02 +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.7; Fri, 14 Jun 2013 22:35:40 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 14 Jun 2013 22:35:59 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Fri, 14 Jun 2013 14:35:49 -0700 From: Leeyoung To: Ina Minei , "adrian@olddog.co.uk" , "'Ramon Casellas'" , Fatai Zhang Thread-Topic: [Pce] Next steps for draft-farrkingel-pce-questions Thread-Index: Ac5neOV6bpyH43/bTpiBxi1xkaK/TAAO+k4AADbRUQAAO9ZlAAAOIdyQ Date: Fri, 14 Jun 2013 21:35:49 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172915584C@dfweml511-mbs.china.huawei.com> References: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> <51B88746.8000603@cttc.es> <01ae01ce6855$689a3ad0$39ceb070$@olddog.co.uk> <70BDAD02381BA54CA31315A2A26A7AD3037EF28C@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037EF28C@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pce@ietf.org" Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions 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, 14 Jun 2013 21:36:10 -0000 I agree with Fatai and Ina on that this draft might be worthy of the consid= eration for an informational RFC.=20 Regards, Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ina M= inei Sent: Friday, June 14, 2013 4:19 PM To: adrian@olddog.co.uk; 'Ramon Casellas'; Fatai Zhang Cc: pce@ietf.org Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions Adrian,=20 I think there is value in this document, and it seems to fit well with an i= nformational document. While I share your concern that some areas are rapid= ly changing, the process of progressing documents is not very fast either, = so there is time and opportunity to update it :-) Ina =20 -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Adria= n Farrel Sent: Thursday, June 13, 2013 9:45 AM To: 'Ramon Casellas' Cc: pce@ietf.org Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions [snip] I suppose the question might be: Could we get to a position where we have covered 90% of the questions that = might arise in subsequent two years? If so, then it would sound like an RFC might be useful. Just like we publis= hed the original framework RFC without keeping it alive for ever as a regul= arly-updated I-D. But if we don't think we can get this stable (perhaps the field is expandin= g too fast) then maybe a wiki?=20 I don't like a wiki for this because it doesn't register consensus or becom= e more widely visible. Cheers, Adrian _______________________________________________ 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 ina@juniper.net Fri Jun 14 14:50:27 2013 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 978F321F99F8 for ; Fri, 14 Jun 2013 14:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.069 X-Spam-Level: * X-Spam-Status: No, score=1.069 tagged_above=-999 required=5 tests=[AWL=1.535, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQb8uzycbHnj for ; Fri, 14 Jun 2013 14:50:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCEA21F99ED for ; Fri, 14 Jun 2013 14:50:20 -0700 (PDT) Received: from mail143-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 21:50:19 +0000 Received: from mail143-va3 (localhost [127.0.0.1]) by mail143-va3-R.bigfish.com (Postfix) with ESMTP id CE6B280104 for ; Fri, 14 Jun 2013 21:50:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zz98dI9371Ic85ah11f6N4015I1447Idbf2izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1c8fb4h18de19h8275bh8275dh19d96biz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail143-va3: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=ina@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail143-va3 (localhost.localdomain [127.0.0.1]) by mail143-va3 (MessageSwitch) id 1371246616329466_1761; Fri, 14 Jun 2013 21:50:16 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.225]) by mail143-va3.bigfish.com (Postfix) with ESMTP id 4A865E0045 for ; Fri, 14 Jun 2013 21:50:16 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Jun 2013 21:50:16 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 14 Jun 2013 14:50:14 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 14 Jun 2013 14:50:14 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 14 Jun 2013 14:53:55 -0700 Received: from mail148-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE035.bigfish.com (10.243.66.100) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 21:50:13 +0000 Received: from mail148-co1 (localhost [127.0.0.1]) by mail148-co1-R.bigfish.com (Postfix) with ESMTP id 6BE36DC0482 for ; Fri, 14 Jun 2013 21:50:13 +0000 (UTC) Received: from mail148-co1 (localhost.localdomain [127.0.0.1]) by mail148-co1 (MessageSwitch) id 1371246610721156_3453; Fri, 14 Jun 2013 21:50:10 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.251]) by mail148-co1.bigfish.com (Postfix) with ESMTP id AD9B5180057; Fri, 14 Jun 2013 21:50:10 +0000 (UTC) Received: from BLUPRD0511HT001.namprd05.prod.outlook.com (157.56.232.213) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Jun 2013 21:50:10 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT001.namprd05.prod.outlook.com ([10.255.135.164]) with mapi id 14.16.0324.000; Fri, 14 Jun 2013 21:50:02 +0000 From: Ina Minei To: "Zhangxian (Xian)" , Ravi Torvi , "adrian@olddog.co.uk" Thread-Topic: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04 Thread-Index: AQHOYYvFFtdzLtgV5kKgMKpl+9UxBpk1yHTg Date: Fri, 14 Jun 2013 21:50:01 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037EF321@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037AFA02@BLUPRD0511MB436.namprd05.prod.outlook.com> <036001ce5fa7$01a6aa40$04f3fec0$@olddog.co.uk>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: multipart/alternative; boundary="_000_70BDAD02381BA54CA31315A2A26A7AD3037EF321BLUPRD0511MB436_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "pce@ietf.org" Subject: Re: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04 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, 14 Jun 2013 21:50:27 -0000 --_000_70BDAD02381BA54CA31315A2A26A7AD3037EF321BLUPRD0511MB436_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Ravi, Thank you for the careful review. I think you bring up very good points on the opportunities active stateful = PCE opens. In particular, the ability to simplify the routers and scale var= ious components, simplify operations, etc. Although this may not directly = translate to a specific use case, I think there is value in discussing thes= e issues in the next version of the draft and will work on adding specific = text. Thank you, Ina From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Zhang= xian (Xian) Sent: Tuesday, June 04, 2013 6:26 PM To: Ravi Torvi; adrian@olddog.co.uk Cc: pce@ietf.org Subject: Re: [Pce] New version of the stateful pce applicability draft - dr= aft-zhang-pce-stateful-pce-app-04 Hi, Ravi, Thank you very much for the useful suggestions. Please find my reply inl= ine: Regards, Xian From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of Ravi Torvi Sent: 2013=1B$BG/=1B(B6=1B$B7n=1B(B5=1B$BF|=1B(B 0:32 To: adrian@olddog.co.uk Cc: pce@ietf.org Subject: Re: [Pce] New version of the stateful pce applicability draft - dr= aft-zhang-pce-stateful-pce-app-04 Hi Ina & Authors, Now that we have new WG charter, I think it is a good time to clarify appli= cability of PCE-Stateful. Following are some of my observations that can be considered in your next r= evisions of draft: 1. We need to scope the PCE-Stateful applicability, i.e., clarify explicitl= y where vanilla PCE can be sufficient or PCE-Stateful could be an overkill. - Similarly, it would be nice to describe deployments of Passive Statef= ul PCE and with Active Stateful PCE separately I think draft describes goodness of Stateful well, however, it should provi= de guidelines for choosing right set of PCE-stateful features. ###: In this version, we did explicitly describe these two different kinds = of stateful PCEs in a variety of use cases since they have different capabi= lities. If you have look at the use cases we have from Section 5, you shoul= d be able to find such update. If there are still things missing , please l= et us know. ###: As for where the stateful PCE is applicable, I think the whole documen= t is trying to say its necessity, I do not see why we need to name examples= where it is not needed. However, we do state the pros and cons of stateful= PCEs here and there as well as in the use cases so as to make it less adve= rtising as JP suggested in last IETF. Few basic applications (I am not sure this draft covers them explicitly) fr= om PCC Scale point of view: 2. I think draft should describe on performance w/ PCE-Stateful i.e., How PCE Stateful helps in dynamic changes compared to NMS based. ###: In this document, we are comparing with a stateless PCE, not NMS. Why = do you think there is such a need to compare with the latter? IMHO, statef= ul PCEs are not trying to replace NMS since they have different utilities. = Just as you mentioned that stateful PCEs can help with dynamic changes, whi= ch I do not think it is what NMS is mainly used for. 3. One obvious applicability of Active PCE-Stateful would be : config scali= ng. Operators do not have to maintain tons of LSP configuration on the box. ###: I do not get your point, are you comparing NMS-based configuration wit= h stateful PCE-based configuration? 4. LSP monitoring is less expensive with PCE Stateful, as PCE is expected t= o maintain complete state. This reduces burden on routers. ###: Again, what entity are you comparing stateful PCE with? Could you elab= orate more? I haven=1B$B!G=1B(Bt thought about this before. BTW, this draft= works for both MPLS-TE and GMPLS controlled networks. So I wonder when you= say =1B$B!H=1B(Bthis reduces burden on routers=1B$B!I=1B(B, do you mean th= is applications are only possible with MPLS-TE networks? Thanks, Ravi http://www.google.com/profiles/pratiravi On Sun, Jun 2, 2013 at 11:36 AM, Adrian Farrel > wrote: Ina, WG, Pleased to see people thinking about applicability and use cases. IMHO, not= enough attention is paid to why we are doing things and how they will be u= sed. Thanks for the work, and hope people will review it (especially service pro= viders!) Adrian From: pce-bounces@ietf.org [mailto:pce-bounces= @ietf.org] On Behalf Of Ina Minei Sent: 26 May 2013 22:52 To: pce@ietf.org Subject: [Pce] New version of the stateful pce applicability draft - draft-= zhang-pce-stateful-pce-app-04 A new version of the stateful pce applicability draft was posted yesterday. In the interest of making progress on this document, the authors would like= to solicit review, comments and discussion from the working group, before = the next IETF meeting. URL: http://www.ietf.org/internet-drafts/draft-zhang-pce-statef= ul-pce-app-04.txt Status: http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-p= ce-app Htmlized: http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-ap= p-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-pce-statefu= l-pce-app-04 Ina and Xian on behalf of all the authors _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --_000_70BDAD02381BA54CA31315A2A26A7AD3037EF321BLUPRD0511MB436_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Ravi,

<= /p>

Thank you for the careful= review.

<= /p>

I think you bring up very= good points on the opportunities active stateful PCE opens. In particular,= the ability to simplify the routers and scale various components, simplify operations, etc. Although this may not directly translate t= o a specific use case, I think there is value in discussing these issues in= the next version of the draft and will work on adding specific text.

<= /p>

Thank you,

<= /p>

Ina

<= /p>

From: pce-boun= ces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Zhangxian (Xian)
Sent: Tuesday, June 04, 2013 6:26 PM
To: Ravi Torvi; adrian@olddog.co.uk
Cc: pce@ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability dra= ft - draft-zhang-pce-stateful-pce-app-04

Hi, Ravi,

<= /p>

Thank you ve= ry much for the useful suggestions. Please find my reply inline:=

<= /p>

Regards,

Xian

<= /p>

From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Ravi Torvi
Sent: 2013=1B$BG/=1B(B6=1B$B7n=1B(B5=1B$BF|=1B(B 0:32
To: adrian@olddog.co.uk Cc: pce@ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability dra= ft - draft-zhang-pce-stateful-pce-app-04

Hi Ina & Authors,

Now that we have new = WG charter, I think it is a good time to clarify applicability of PCE-State= ful.

Following are some of my observations that can be considered in your next r= evisions of draft:

1. We need to scope the PCE-Stateful applicability, = i.e., clarify explicitly where vanilla PCE can be sufficient or PCE-Statefu= l could be an overkill.

- = Similarly, it would be nice to describe deployments of Passive Stateful PCE= and with Active Stateful PCE separately

I think draft describes goodness of Stateful well, h= owever, it should provide guidelines for choosing right set of PCE-stateful= features.

###: In this version, = we did explicitly describe these two different kinds of stateful PCEs in a = variety of use cases since they have different capabilities. If you have lo= ok at the use cases we have from Section 5, you should be able to find such update. If there are still things missi= ng , please let us know.

###: As for where the = stateful PCE is applicable, I think the whole document is trying to say its= necessity, I do not see why we need to name examples where it is not neede= d. However, we do state the pros and cons of stateful PCEs here and there as well as in the use cases so as to = make it less advertising as JP suggested in last IETF.

<= /p>

Few basic application= s (I am not sure this draft covers them explicitly) from PCC Scale point of= view:

2. I think draft should describe on performance w/ PCE-Stateful
i.e., How PCE Stateful helps in dynamic changes compared= to NMS based.

###: In this document, we are comparing with a stateless PCE, not NMS= . Why do you think there is such a need to compare with the latter? IMHO, stateful PCEs are not trying to replace NMS since they= have different utilities. Just as you mentioned that stateful PCEs can hel= p with dynamic changes, which I do not think it is what NMS is mainly used = for.

3. One obvious applic= ability of Active PCE-Stateful would be : config scaling. Operators do not = have to maintain tons of LSP configuration on the box.

###: I do not get your point, are you comparing NMS-based configurati= on with stateful PCE-based configuration?

4. LSP monitoring is = less expensive with PCE Stateful, as PCE is expected to maintain complete s= tate.
This reduces burden on routers.

###: Again, what entity are you comparing stateful PCE with? Could yo= u elaborate more? I haven=1B$B!G=1B(Bt thought about this before. BTW, this draft works for both MPLS-TE and GMPLS controlled networks. So I wond= er when you say =1B$B!H=1B(Bthis reduces burden on routers=1B$B!I=1B(B, do = you mean this applications are only possible with MPLS-TE networks? <= o:p>

Thanks,
Ravi

http://www.google.com/profiles/pratiravi

On Sun, Jun 2, 2013 at 11:36 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

Ina, WG,

Pleased to see people th= inking about applicability and use cases. IMHO, not enough attention is paid to why we are doing things and how they will be used.

Thanks for the work, and= hope people will review it (especially service providers!)

Adrian

A new version of the stateful pce applicability draft was posted yesterd= ay.

In the interest of making progress on this document, the authors would l= ike to solicit review, comments and discussion from the working group, before the next IETF meeting.

URL: &n= bsp; http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt=

Status: http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app=

Htmlized: http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04

Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-zhang-pce-stateful-pce-app-04<= /span>

Ina and Xian on behalf of all the auth= ors

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

--_000_70BDAD02381BA54CA31315A2A26A7AD3037EF321BLUPRD0511MB436_-- From julien.meuric@orange.com Mon Jun 17 08:44:11 2013 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 CFC5E21F9CAF for ; Mon, 17 Jun 2013 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhdP9L98OweF for ; Mon, 17 Jun 2013 08:44:06 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C703821F9D33 for ; Mon, 17 Jun 2013 08:43:56 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B409C5D8A8B; Mon, 17 Jun 2013 17:43:55 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 7764E5D8A7C; Mon, 17 Jun 2013 17:43:45 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 17:43:45 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jun 2013 17:43:44 +0200 Message-ID: <51BF2EAD.1000601@orange.com> Date: Mon, 17 Jun 2013 17:43:41 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> In-Reply-To: <11a101ce6778$e9eb4710$bdc1d530$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2013 15:43:45.0167 (UTC) FILETIME=[736309F0:01CE6B71] Cc: pce@ietf.org Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions 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, 17 Jun 2013 15:44:11 -0000 Hi all. As individual, I share the views expressed on the list: now that the I-D exists, it would be a pity to let it die. Contrary to elephants, human beings forget, so I would say: "go for an RFC!" Chair hat on, I thinks that: - RFC errata is out of scope: it is supposed to be used for document fixes, not updates; - the choice between WG stream and individual streams remains in authors' hands (just note that, based on the feedback seen on the list, it would make sense to poll for WG adoption); - I am not really comfortable with the option refered to as "publication of the individual I-D under the care of the WG" because "under the care of the WG" is not clear to me in that context; - in any case, once published as an RFC, nothing prevents from submitting a volume 2 later ("PCE FAQ: the pachyderm returns [for peanuts]"). Regards, Julien On 06/12/2013 16:27, Adrian Farrel wrote: > Hi chairs and working group, > > Dan and I are wondering what to do with this draft. > > It seems that a number of people have been reading it and have found it useful > or at least stimulating. > > At the moment, it represents just the rambling thoughts of two individuals, so > my question is really whether the WG thinks this would be something that could > be usefully published as an RFC or should be judged to have served its purpose > now and allowed to die. > > If published as an RFC there would be a number of ways to go forward: adoption > by the WG and subsequent edits; publication of the individual I-D under the care > of the WG (still review and edit, but faster); publication as an individual I-D > (under the care of an AD with review by the PCE working group). > > We'd be interested to know what you think before we decide what action to > request for the document. > > And, of course, any issues or thoughts on the document would be very welcome. > > Thanks, > Adrian > > > From ogondio@tid.es Mon Jun 17 09:10:11 2013 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 ADA7121F9CD4 for ; Mon, 17 Jun 2013 09:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8An06gwUKeky for ; Mon, 17 Jun 2013 09:10:06 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id A036921F9051 for ; Mon, 17 Jun 2013 09:10:04 -0700 (PDT) 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 <0MOJ00MPWOUWVW@tid.hi.inet> for pce@ietf.org; Mon, 17 Jun 2013 18:10:01 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id A0.3D.05654.8D43FB15; Mon, 17 Jun 2013 18:10:01 +0200 (CEST) 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 <0MOJ00M1EOWOVW@tid.hi.inet> for pce@ietf.org; Mon, 17 Jun 2013 18:10:00 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 18:10:00 +0200 Date: Mon, 17 Jun 2013 16:09:05 +0000 From: =?Windows-1252?Q?Oscar_Gonz=E1lez_de_Dios?= X-Originating-IP: [10.95.64.115] To: "pce@ietf.org" , "draft-ietf-pce-pcep-inter-domain-p2mp-procedures@tools.ietf.org" Message-id: <7CFF94B047D8864CB6268315034E35DE2F5E9F98@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uk8Jx89qi+g/p+HRq2+BjA)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 Thread-index: AQHOa3UeK5pIZROfjUeTXvCIKVVidQ== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7f4b6d000001616-8e-51bf34d8ab77 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsXCFe9nqHvTZH+gQetkJoum+zfYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXnxK6aCxhbGituNe1kaGLfmdTFycEgImEg0/JXpYuQEMsUk Ltxbz9bFyMUhJLCdUWLGzLcsEM53Ron9DYfYQaqEBKYxSvy+YA5iswioSjyZOJERxGYTcJJo 6DkPZgsLuEmcm9POBjFVQeLPucdgg0QEVjFK9HZeARvEK+AtceXUVkYIW1Dix+R7LCAXMQvk SmxeGwUSZhYQl5jzayIriM0oICux8vxpsHIRoNZTR2cwQdh6En0nJ4GNFAWy246dYYfYKyCx ZM95ZghbVOLl43+sExhFZiHZNgth2ywk2yBsA4n35+YzQ9jaEssWvoay9SU2fjnLCGGbSTxY e4gVWc0CRo5VjGLFSUWZ6RkluYmZOekGRnoZmXqZeaklmxgh0ZW5g3H5TpVDjAIcjEo8vBwi +wOFWBPLiitzDzFKcDArifDGTtwXKMSbklhZlVqUH19UmpNafIiRiYNTqoFRg8l+/oH5Iqar zIsTGFlfy/2+9mnfWTXeBZ/8OfkOXVNWn2JmmiL2yYMzhPtH7YVHLzyV5BOvShxdMyty2oXb 4dvXmX+LMLiRLnvo6q3X8rIB+RHLfzHM2NrTpGh3iz3C1nZp5p0Nv++LyHNOfZQYcSMpfNu3 hn//CjPmuN14J/uc4cv6kC4uJZbijERDLeai4kQA72A/GYwCAAA= Subject: [Pce] Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 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, 17 Jun 2013 16:10:11 -0000 --Boundary_(ID_uk8Jx89qi+g/p+HRq2+BjA) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04, Please find bellow some comments regarding the PCEP P2MP Procedures draft = (sorry for sending them after the 2 weeks deadline for the LC comments): - There is a strange page jump in the Terminology section. After "RFC5862]"= and "ABR: " there is whole blank page=85 - Terminology section: Blank line missing between Transit/branch domain and= VSPT - During the document there are 3 different acronyms "P2MP LSP" (section 3 = ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE LSP" (the most co= mmon in the document). I suggest aligning the terminology and always use th= e same term to avoid confusion. . For "historical" reasons, "P2MP TE LSP", = used in RFC 4461 seems appropriate. The definition of P2M2 TE LSP used in R= FC 4661 may be cited too in the terminology section for completeness. - In the terminology section the term "Boundary node (BN) is defined. Howev= er, later on, the term "border node" is also used, presumably as an synonym= . I suggest either choose one term for the whole document or include the te= rm border node too in the terminology. - Section 3. The sentence "A sub-tree is a part of the P2MP tree describing= how the root or an intermediate P2MP LSPs minimizes packet duplication whe= n P2P TE sub-LSPs traverse common links" is hard to understand (maybe there= is a typo and it should say "the root of an intermediate P2P LSP"). - The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined in RF= C 4661. Maybe it should be worth adding the sub-LSP terms it to the termino= logy section. - In section 4 the term "sequence of domains" is also used to refer to the = path domain tree. This introduces confusion, as there is also a "domain seq= uence" term which applies only to P2P. Please use always "path domain tree" -Section 4, 2nd paragraph, "domain path tree", use the term "path domain tr= ee" defined in the terminology section. - Section 4, figure 1 legend is "Domain sequence tree". This term is not de= fined in the terminology. I would prefer to stick to the term "Path Domain = tree". Sorry to be picky about the terminology, but reading the document is= hard when the terms are mixed as they are very alike=85. - Section 4, assumptions, first bullet. Where it says " each of the P2MP de= stination" it should day "each of the P2MP destinations". Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each doma= in in the path domain tree)". I don't get this point=85. Initially it was s= tated that the path domain tree is known. In this point, is it suggested an= alternative to knowing the path domain tree? That is, instead of assuming = that the path domain tree is known, what is known is a set of PCEs? Please = clarify Section 4, assumption 1, How is the set of PCEs and their relationships exc= hanged? What are the relationships that need to be exchanged? Section 4, assumptions, I guess, there is an (maybe obvious) assumptions th= at the association domain - PCE is known in advance. Sesction 4, assumption 4. "The boundary nodes to use on the LSP are pre-det= ermined". Does this mean then that both the path domain tree AND the bounda= ry nodes are known in advance for each possible P2MP combination? At this point there is something I miss=85 Later, in section 7, it is ment= ioned that a core tree is computed. However, it seems from the assumptions = that the core tree is fixed in advance=85 Maybe I am mis-interpreting the a= ssumptions=85 Please clarify the assumptions of what is really pre-determin= ed and what is computed. Section 5. requirement 4. I suggest using better "PCReq and PCEReq messages= " using the terminology of RFC 5440. Section 5. The requirements from 5 to 8 are not written like requirements. = I suggest re-writing them with requirements language. Section 6. Objective function 3. The definition of the core tree in the te= rminology section considers ONLY entry boundary nodes as leaves. However, i= t seems here both entry and exit BNs are considered. Please clarify=85 (may= be it should be mentioned only BNs without distinction among entry or exit)= . Section 6. Objective function 3 is about limiting the number of entry point= s to a domain. Why would there be more that one entry point to a domain? I = would expect multiple exit points (that is, several boundary nodes to exit = to other domains in the tree). Also, given that, by the assumptions in sect= ion 4, the path domain tree AND the boundary nodes are flxed, I do not know= if this objective function has any impact at all=85. In any case, limiting the number of entry points may an additional constrai= nt to the previous objective functions=85 It seems more a metric constraint= rather than an objective function.. Also, is it considered that several of this objective functions can be appl= ied or combined? Section 6, objective function 4=85 I don't get that one=85 could you clarif= y it? Section 7.1 The sentence "An optimal core-tree [based on the OF] will be co= mputed with analyzing the nodes and links within the domains" sounds a bit = strange=85 maybe the "with" is not needed in the sentence? Also.. Previousl= y it was mentioned that the core-tree was formed only considering entry and= exit nodes, but now, it seems that the core-tree is obtained taking into a= ccount the whole set of nodes and links=85 Please clarify here (or clarify = objective function 2 where it says "formed by considering only the entry an= d exit nodes"=85) - Section 7.3 When mentioning the request with the C bit set I suggest add= ing "(defined later in section 7.4.1 of this document)", as it is a new fla= g=85 - Section 7.4.2. I guess "domain-sequence" is really the domain tree=85 One= question=85 the PCE sequence=85 is a PCE tree? And that's all :-) I hope the comments can be useful to improve the readabi= lity of the draft. Best Regards, Oscar ________________________________ 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_uk8Jx89qi+g/p+HRq2+BjA) Content-id: Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-= 04,

Please= find bellow some comments regarding the PCEP P2MP Procedures dr= aft (sorry for sending them after the 2 weeks deadline for the LC comments)= :

- Ther= e is a strange page jump in the Terminology section. After "RFC5862]&q= uot; and "ABR: " there is whole blank page=85

- = ;Terminology section: Blank line missing between Transit/branch domain= and VSPT

- Duri= ng the document there are 3 different acronyms "P2MP LSP" (sectio= n 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP T= E LSP" (the most common in the document). I suggest aligning the terminology and always use the same term to avoid confusion. . For &qu= ot;historical" reasons, "P2MP TE LSP", used in RFC 4461 seem= s appropriate. The definition of P2M2 TE LSP used in RFC 4661 may be cited = too in the terminology section for completeness.

- In t= he terminology section the term "Boundary node (BN) is defined. Howeve= r, later on, the term "border node" is also used, presumably as a= n synonym. I suggest either choose one term for the whole document or include the term border node too in the terminology.&nbs= p;

- Sect= ion 3. The sentence "A sub-tree is a part of the P2MP tree descri= bing how the root or an intermediate P2MP LSPs minimizes packet duplic= ation when P2P TE sub-LSPs traverse common links" is hard to understand (maybe there is a typo and it should say "the root= of an intermediate P2P LSP").

- The = term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined in RFC 4661= . Maybe it should be worth adding the sub-LSP terms it to the terminology s= ection.

- In s= ection 4 the term "sequence of domains" is also used to refer to = the path domain tree. This introduces confusion, as there is also a "d= omain sequence" term which applies only to P2P. Please use always "path domain tree"

-Secti= on 4, 2nd paragraph, "domain path tree", use the term "path = domain tree" defined in the terminology section.

- Sect= ion 4, figure 1 legend is "Domain sequence tree". This term is no= t defined in the terminology. I would prefer to stick to the term "Pat= h Domain tree". Sorry to be picky about the terminology, but reading the document is hard when the terms are mixed as they are very= alike=85.

- Sect= ion 4, assumptions, first bullet. Where it says " each of the P2MP des= tination" it should day "each of the P2MP destinations".

Sectio= n 4, assumption 1, "or PCE sequence (i.e. PCE th= at serves each domain in the path domain tree)". I don't get this poin= t=85. Initially it was stated that the path domain tree is known. In this point, is it suggested an alternative to knowing the path domain tree= ? That is, instead of assuming that the path domain tree is known, what is = known is a set of PCEs? Please clarify

Sectio= n 4, assumption 1, How is the set of PCEs and their relationships exchanged= ? What are the relationships that need to be exchanged?

Sectio= n 4, assumptions, I guess, there is an (maybe obvious) assumptions that the= association domain - PCE is known in advance.

Sescti= on 4, assumption 4. "The boundary nodes to use on the LSP are pre-dete= rmined". Does this mean then that both the path domain tree AND the bo= undary nodes are known in advance for each possible P2MP combination?

At thi= s point there is something I miss=85 Later, in section 7, it is menti= oned that a core tree is computed. However, it seems from the assumptions t= hat the core tree is fixed in advance=85 Maybe I am mis-interpreting the assumptions=85 Please clarify the assumptions of= what is really pre-determined and what is computed.

Sectio= n 5. requirement 4. I suggest using better "PCReq and PCEReq messages&= quot; using the terminology of RFC 5440.

Sectio= n 5. The requirements from 5 to 8 are not written like requirements. I sugg= est re-writing them with requirements language.

Section 6. Objective function 3. The definition of the core tree = ;in the terminology section considers ONLY entry boundary nodes as leaves. = However, it seems here both entry and exit BNs are considered. Please clari= fy=85 (maybe it should be mentioned only BNs without distinction among entry or exit).

Sectio= n 6. Objective function 3 is about limiting the number of entry points to a= domain. Why would there be more that one entry point to a domain? I would = expect multiple exit points (that is, several boundary nodes to exit to other domains in the tree). Also, given = that, by the assumptions in section 4, the path domain tree AND the boundar= y nodes are flxed, I do not know if this objective function has any impact = at all=85.

In any= case, limiting the number of entry points may an additional constraint to = the previous objective functions=85 It seems more a metric constraint rathe= r than an objective function..

Also, = is it considered that several of this objective functions can be applied or= combined?

Sectio= n 6, objective function 4=85 I don't get that one=85 could you clarify it?<= /div>

Sectio= n 7.1 The sentence "An optimal core-tree [based on the OF] will be com= puted with analyzing the nodes and links within the domains" soun= ds a bit strange=85 maybe the "with" is not needed in the sentence? Also.. Previously it was mentioned that the core-tree was fo= rmed only considering entry and exit nodes, but now, it seems that the core= -tree is obtained taking into account the whole set of nodes and links=85 P= lease clarify here (or clarify objective function 2 where it says "formed by considering only the entry and ex= it nodes"=85)

- &nbs= p;Section 7.3 When mentioning the request with the C bit set I suggest addi= ng "(defined later in section 7.4.1 of this document)", as it is = a new flag=85

- Sect= ion 7.4.2. I guess "domain-sequence" is really the domain tree=85= One question=85 the PCE sequence=85 is a PCE tree?

And th= at's all :-) I hope the comments can be useful to improve the readability o= f the draft.

= Best Regards,

Oscar&= nbsp;

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_uk8Jx89qi+g/p+HRq2+BjA)-- From daniel@olddog.co.uk Mon Jun 17 22:48:06 2013 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 3002A21F9DCD for ; Mon, 17 Jun 2013 22:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.144 X-Spam-Level: X-Spam-Status: No, score=-100.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhN5VWX0VuXk for ; Mon, 17 Jun 2013 22:48:01 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A821F9D92 for ; Mon, 17 Jun 2013 22:48:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5I5lwD6010981; Tue, 18 Jun 2013 06:47:58 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5I5lsCe010938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 06:47:56 +0100 From: "Daniel King" To: "=?iso-8859-1?Q?'Oscar_Gonz=E1lez_de_Dios'?=" , , References: <7CFF94B047D8864CB6268315034E35DE2F5E9F98@EX10-MB2-MAD.hi.inet> In-Reply-To: <7CFF94B047D8864CB6268315034E35DE2F5E9F98@EX10-MB2-MAD.hi.inet> Date: Tue, 18 Jun 2013 06:47:53 +0100 Message-ID: <013501ce6be7$61378910$23a69b30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01CE6BEF.C2FF7380" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHZuKuBsgLNsNOSdzgjZ4hsHKP0Q5kkXNTg Content-Language: en-gb Subject: Re: [Pce] Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 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: Tue, 18 Jun 2013 05:48:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0136_01CE6BEF.C2FF7380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Oscar! This will really help improve the readability of the = draft. We will update the draft, but also respond to each of the points = specifically and clarify any technical issues. =20 =20 Br, Dan.=20 =20 From: Oscar Gonz=E1lez de Dios [mailto:ogondio@tid.es]=20 Sent: 17 June 2013 17:09 To: pce@ietf.org; draft-ietf-pce-pcep-inter-domain-p2mp-procedures@tools.ietf.org Subject: Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 =20 Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04, =20 Please find bellow some comments regarding the PCEP P2MP Procedures = draft (sorry for sending them after the 2 weeks deadline for the LC comments): =20 - There is a strange page jump in the Terminology section. After = "RFC5862]" and "ABR: " there is whole blank page=85 =20 - Terminology section: Blank line missing between Transit/branch domain = and VSPT =20 - During the document there are 3 different acronyms "P2MP LSP" (section = 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE LSP" (the most common in the document). I suggest aligning the terminology and always = use the same term to avoid confusion. . For "historical" reasons, "P2MP TE = LSP", used in RFC 4461 seems appropriate. The definition of P2M2 TE LSP used = in RFC 4661 may be cited too in the terminology section for completeness. =20 - In the terminology section the term "Boundary node (BN) is defined. However, later on, the term "border node" is also used, presumably as an synonym. I suggest either choose one term for the whole document or = include the term border node too in the terminology.=20 =20 - Section 3. The sentence "A sub-tree is a part of the P2MP tree = describing how the root or an intermediate P2MP LSPs minimizes packet duplication = when P2P TE sub-LSPs traverse common links" is hard to understand (maybe = there is a typo and it should say "the root of an intermediate P2P LSP").=20 - The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined in = RFC 4661. Maybe it should be worth adding the sub-LSP terms it to the terminology section. - In section 4 the term "sequence of domains" is also used to refer to = the path domain tree. This introduces confusion, as there is also a "domain sequence" term which applies only to P2P. Please use always "path domain tree" =20 -Section 4, 2nd paragraph, "domain path tree", use the term "path domain tree" defined in the terminology section. - Section 4, figure 1 legend is "Domain sequence tree". This term is not defined in the terminology. I would prefer to stick to the term "Path = Domain tree". Sorry to be picky about the terminology, but reading the document = is hard when the terms are mixed as they are very alike=85. =20 - Section 4, assumptions, first bullet. Where it says " each of the P2MP destination" it should day "each of the P2MP destinations". =20 Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each domain in the path domain tree)". I don't get this point=85. Initially = it was stated that the path domain tree is known. In this point, is it = suggested an alternative to knowing the path domain tree? That is, instead of = assuming that the path domain tree is known, what is known is a set of PCEs? = Please clarify =20 Section 4, assumption 1, How is the set of PCEs and their relationships exchanged? What are the relationships that need to be exchanged? =20 Section 4, assumptions, I guess, there is an (maybe obvious) assumptions that the association domain - PCE is known in advance. =20 Sesction 4, assumption 4. "The boundary nodes to use on the LSP are pre-determined". Does this mean then that both the path domain tree AND = the boundary nodes are known in advance for each possible P2MP combination? At this point there is something I miss=85 Later, in section 7, it is mentioned that a core tree is computed. However, it seems from the assumptions that the core tree is fixed in advance=85 Maybe I am mis-interpreting the assumptions=85 Please clarify the assumptions of = what is really pre-determined and what is computed. =20 Section 5. requirement 4. I suggest using better "PCReq and PCEReq = messages" using the terminology of RFC 5440. =20 Section 5. The requirements from 5 to 8 are not written like = requirements. I suggest re-writing them with requirements language.=20 =20 Section 6. Objective function 3. The definition of the core tree in the terminology section considers ONLY entry boundary nodes as leaves. = However, it seems here both entry and exit BNs are considered. Please clarify=85 = (maybe it should be mentioned only BNs without distinction among entry or = exit). =20 Section 6. Objective function 3 is about limiting the number of entry = points to a domain. Why would there be more that one entry point to a domain? I would expect multiple exit points (that is, several boundary nodes to = exit to other domains in the tree). Also, given that, by the assumptions in section 4, the path domain tree AND the boundary nodes are flxed, I do = not know if this objective function has any impact at all=85.=20 In any case, limiting the number of entry points may an additional constraint to the previous objective functions=85 It seems more a metric constraint rather than an objective function..=20 Also, is it considered that several of this objective functions can be applied or combined? =20 Section 6, objective function 4=85 I don't get that one=85 could you = clarify it? =20 Section 7.1 The sentence "An optimal core-tree [based on the OF] will be computed with analyzing the nodes and links within the domains" sounds a = bit strange=85 maybe the "with" is not needed in the sentence? Also.. = Previously it was mentioned that the core-tree was formed only considering entry = and exit nodes, but now, it seems that the core-tree is obtained taking into account the whole set of nodes and links=85 Please clarify here (or = clarify objective function 2 where it says "formed by considering only the entry = and exit nodes"=85) =20 - Section 7.3 When mentioning the request with the C bit set I suggest adding "(defined later in section 7.4.1 of this document)", as it is a = new flag=85=20 =20 - Section 7.4.2. I guess "domain-sequence" is really the domain tree=85 = One question=85 the PCE sequence=85 is a PCE tree?=20 =20 And that's all :-) I hope the comments can be useful to improve the readability of the draft. =20 Best Regards, =20 Oscar=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 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 ------=_NextPart_000_0136_01CE6BEF.C2FF7380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Oscar! This will really help = improve the readability of the draft. We will update the draft, but also = respond to each of the points specifically and clarify any technical = issues. =A0

Br, Dan.

From: Oscar = Gonz=E1lez de Dios [mailto:ogondio@tid.es]
Sent: 17 June 2013 = 17:09
To: pce@ietf.org; = draft-ietf-pce-pcep-inter-domain-p2mp-procedures@tools.ietf.org
Sub= ject: Review of = draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04

Dear authors = of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04,

Please find bellow some comments regarding the PCEP P2MP = Procedures draft (sorry for sending them after the 2 weeks = deadline for the LC comments):

- There is a strange page jump in the Terminology section. After = "RFC5862]" and "ABR: " there is whole blank = page…

- Terminology section: Blank line missing between = Transit/branch domain and VSPT

- During the document there are 3 different acronyms "P2MP = LSP" (section 3 ) "P2MP TE-LSP" (this one only in section = 6) and "P2MP TE LSP" (the most common in the document). I = suggest aligning the terminology and always use the same term to avoid = confusion. . For "historical" reasons, "P2MP TE = LSP", used in RFC 4461 seems appropriate. The definition of P2M2 TE = LSP used in RFC 4661 may be cited too in the terminology section for = completeness.

- In the terminology section the term "Boundary node (BN) is = defined. However, later on, the term "border node" is also = used, presumably as an synonym. I suggest either choose one term for the = whole document or include the term border node too in the = terminology.

- Section 3. The sentence "A sub-tree is a part of the P2MP = tree describing how the root or an intermediate P2MP LSPs minimizes = packet duplication when P2P TE sub-LSPs traverse common links" = is hard to understand (maybe there is a typo and it should say "the = root of an intermediate P2P = LSP").

- The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined = in RFC 4661. Maybe it should be worth adding the sub-LSP terms it to the = terminology section.

- In section 4 the term "sequence of domains" is also used to = refer to the path domain tree. This introduces confusion, as there is = also a "domain sequence" term which applies only to P2P. = Please use always "path domain = tree"

-Section 4, 2nd paragraph, "domain path tree", use the term = "path domain tree" defined in the terminology = section.

- Section 4, figure 1 legend is "Domain sequence tree". This = term is not defined in the terminology. I would prefer to stick to the = term "Path Domain tree". Sorry to be picky about the = terminology, but reading the document is hard when the terms are mixed = as they are very alike….

- Section 4, assumptions, first bullet. Where it says " each of = the P2MP destination" it should day "each of the P2MP = destinations".

Section 4, assumption 1, "or PCE sequence = (i.e. PCE that serves each domain in the path domain tree)". I = don't get this point…. Initially it was stated that the path = domain tree is known. In this point, is it suggested an alternative to = knowing the path domain tree? That is, instead of assuming that the path = domain tree is known, what is known is a set of PCEs? Please = clarify

Section 4, assumption 1, How is the set of PCEs and their relationships = exchanged? What are the relationships that need to be = exchanged?

Section 4, assumptions, I guess, there is an (maybe obvious) = assumptions that the association domain - PCE is known in = advance.

Sesction 4, assumption 4. "The boundary nodes to use on the LSP = are pre-determined". Does this mean then that both the path domain = tree AND the boundary nodes are known in advance for each possible P2MP = combination?

At this point there is something I miss… Later, in section = 7, it is mentioned that a core tree is computed. However, it seems from = the assumptions that the core tree is fixed in advance… Maybe I am = mis-interpreting the assumptions… Please clarify the assumptions = of what is really pre-determined and what is = computed.

Section 5. requirement 4. I suggest using better "PCReq and PCEReq = messages" using the terminology of RFC = 5440.

Section 5. The requirements from 5 to 8 are not written like = requirements. I suggest re-writing them with requirements = language.

Section 6. Objective function 3. The definition of the core tree = in the terminology section considers ONLY entry boundary nodes as = leaves. However, it seems here both entry and exit BNs are considered. = Please clarify… (maybe it should be mentioned only BNs without = distinction among entry or exit).

Section 6. Objective function 3 is about limiting the number of entry = points to a domain. Why would there be more that one entry point to a = domain? I would expect multiple exit points (that is, several boundary = nodes to exit to other domains in the tree). Also, given that, by the = assumptions in section 4, the path domain tree AND the boundary nodes = are flxed, I do not know if this objective function has any impact at = all….

In any case, limiting the number of entry points may an additional = constraint to the previous objective functions… It seems more a = metric constraint rather than an objective = function..

Also, is it considered that several of this objective functions can be = applied or combined?

Section 6, objective function 4… I don't get that one… = could you clarify it?

Section 7.1 The sentence "An optimal core-tree [based on the OF] = will be computed with analyzing the nodes and links within the = domains" sounds a bit strange… maybe the "with" is = not needed in the sentence? Also.. Previously it was mentioned that the = core-tree was formed only considering entry and exit nodes, but now, it = seems that the core-tree is obtained taking into account the whole set = of nodes and links… Please clarify here (or clarify objective = function 2 where it says "formed by considering only the entry and = exit nodes"…)

- Section 7.3 When mentioning the request with the C bit set I = suggest adding "(defined later in section 7.4.1 of this = document)", as it is a new = flag…

- Section 7.4.2. I guess "domain-sequence" is really the = domain tree… One question… the PCE sequence… is a PCE = tree?

And that's all :-) I hope the comments can be useful to improve the = readability of the draft.

Best Regards,

Oscar

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/E= S/PAGINAS/disclaimer.aspx

------=_NextPart_000_0136_01CE6BEF.C2FF7380-- From julien.meuric@orange.com Wed Jun 19 06:38:15 2013 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 5097B21F91A5 for ; Wed, 19 Jun 2013 06:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4hYLkHSjLIO for ; Wed, 19 Jun 2013 06:38:10 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id BC41921F9C13 for ; Wed, 19 Jun 2013 06:38:08 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 81BCE5D8AA1 for ; Wed, 19 Jun 2013 15:38:07 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 79DEF5D8A8F for ; Wed, 19 Jun 2013 15:38:07 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 15:38:07 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 15:38:06 +0200 Message-ID: <51C1B43E.50605@orange.com> Date: Wed, 19 Jun 2013 15:38:06 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2013 13:38:06.0807 (UTC) FILETIME=[3B001670:01CE6CF2] Subject: [Pce] Poll for Adoption of draft-farrkingel-pce-questions 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: Wed, 19 Jun 2013 13:38:15 -0000 Dear WG, Following the discussion about the future of the aforementioned document and the feedback sent to the list, this message starts a poll for the adoption of draft-farrkingel-pce-questions-03 by the PCE WG. Pay attention to the document scope: the goal is _not_ to leave the I-D open to gather all questions about PCE, but to store some useful text associated to PCE by moving forward as an informational document. Please send your support/opposition to the PCE mailing list (the latter typically requiring some explanation). Detailed comments on the I-D are also welcome. Thanks, JP & Julien From ogondio@tid.es Wed Jun 19 06:41:02 2013 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 5419121F99DC for ; Wed, 19 Jun 2013 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAIvw1rTcyMj for ; Wed, 19 Jun 2013 06:40:58 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0308B21F92EB for ; Wed, 19 Jun 2013 06:40:58 -0700 (PDT) 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 <0MON006F07C81H@tid.hi.inet> for pce@ietf.org; Wed, 19 Jun 2013 15:40:56 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id D9.21.05654.8E4B1C15; Wed, 19 Jun 2013 15:40:56 +0200 (CEST) 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 <0MON00K3B7C8FX@tid.hi.inet> for pce@ietf.org; Wed, 19 Jun 2013 15:40:56 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 15:40:56 +0200 Date: Wed, 19 Jun 2013 13:39:59 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: <51C1B43E.50605@orange.com> X-Originating-IP: [10.95.64.115] To: Julien Meuric , "pce@ietf.org" Message-id: <7CFF94B047D8864CB6268315034E35DE2F5EAF88@EX10-MB2-MAD.hi.inet> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Thread-index: AQHObPJEz+dJaOwmjkqpaMNouchOZZk9C2iA user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7f4b6d000001616-8b-51c1b4e871bb X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsXCFe9nqPtiy8FAgzUzVSya7t9gd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo6VjxkL9nJWfFvXyd7A+IS9i5GTQ0LAROJoz31GCFtM4sK9 9WwgtpDAdkaJF9N5uhi5gOzvjBKr+06zQTgbGCVm73/K2sXIwcEioCpx72QJSAObgIPEukW9 YM3CAm4S1xceZgaxOQU0JF4tW8QMsUBB4s+5xywgtoiAt8S3a49YQWxeIHvqkRdgNrOAmcSF 9rXsEHFBiR+T77FAxHUker9/Y4awxSXm/JoIVa8t8eTdBTCbUUBWYuX504wQ890lrnycwQph G0n8fvmUCcQWFdCTaDt2Bup5AYkle85D3SYq8fLxP9YJjOKzkJwxC8kZs5CcMQvJGbOQnLGA kXUVo1hxUlFmekZJbmJmTrqBkV5Gpl5mXmrJJkZIdGXuYFy+U+UQowAHoxIPb8PKA4FCrIll xZW5hxglOJiVRHgrZh4MFOJNSaysSi3Kjy8qzUktPsTIxMEp1cCY7Je8yoLF2J33k6x8Ht+b u3J9aw5k1a6dmyCx/15bXkjhsWMZBoK+q3+tCj552enprDAX5RtOL4/Jlk2NrAw/f/mi79Wu me1vdufNPuf4Le4iW5lNFs+j0y+3r3dYMWWxX8mMkOC+yOf7X5wO5D0SJFAwc6XxQZMDvxdy PH72MPFRu8umzTtuKLEUZyQaajEXFScCANaR6saMAgAA Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions 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: Wed, 19 Jun 2013 13:41:02 -0000 Yes support. Best Regards, Oscar >Dear WG, > >Following the discussion about the future of the aforementioned document >and the feedback sent to the list, this message starts a poll for the >adoption of draft-farrkingel-pce-questions-03 by the PCE WG. >Pay attention to the document scope: the goal is _not_ to leave the I-D >open to gather all questions about PCE, but to store some useful text >associated to PCE by moving forward as an informational document. > >Please send your support/opposition to the PCE mailing list (the latter >typically requiring some explanation). Detailed comments on the I-D are >also welcome. > >Thanks, > >JP & Julien > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce ________________________________ 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 sergio.belotti@alcatel-lucent.com Wed Jun 19 06:44:24 2013 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 8124021F9C32 for ; Wed, 19 Jun 2013 06:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mz6gf9sCVRA for ; Wed, 19 Jun 2013 06:44:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C83B121F9C2B for ; Wed, 19 Jun 2013 06:44:18 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r5JDiGeI016776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2013 08:44:17 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r5JDhsZZ028768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 09:44:16 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Jun 2013 09:44:04 -0400 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.171]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 19 Jun 2013 15:43:35 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Julien Meuric Thread-Topic: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Thread-Index: AQHObPJLEGuqfuAeO0+RuwVrfzbmLJk9C/ew Date: Wed, 19 Jun 2013 13:43:35 +0000 Message-ID: References: <51C1B43E.50605@orange.com> In-Reply-To: <51C1B43E.50605@orange.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "pce@ietf.org" Subject: [Pce] R: Poll for Adoption of draft-farrkingel-pce-questions 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: Wed, 19 Jun 2013 13:44:24 -0000 Support Best Regards Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] Per conto di Julien = Meuric Inviato: Wednesday, June 19, 2013 3:38 PM A: pce@ietf.org Oggetto: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Dear WG, Following the discussion about the future of the aforementioned document=20 and the feedback sent to the list, this message starts a poll for the=20 adoption of draft-farrkingel-pce-questions-03 by the PCE WG. Pay attention to the document scope: the goal is _not_ to leave the I-D=20 open to gather all questions about PCE, but to store some useful text=20 associated to PCE by moving forward as an informational document. Please send your support/opposition to the PCE mailing list (the latter=20 typically requiring some explanation). Detailed comments on the I-D are=20 also welcome. Thanks, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Wed Jun 19 08:06:09 2013 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 509E121F93D7 for ; Wed, 19 Jun 2013 08:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0awxn7WTjrd for ; Wed, 19 Jun 2013 08:06:04 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 377B121F9A0D for ; Wed, 19 Jun 2013 08:06:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5JF62Sr007659; Wed, 19 Jun 2013 16:06:02 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5JF5vh0007577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 16:05:59 +0100 From: "Adrian Farrel" To: "'Julien Meuric'" , References: <51C1B43E.50605@orange.com> In-Reply-To: <51C1B43E.50605@orange.com> Date: Wed, 19 Jun 2013 16:05:55 +0100 Message-ID: <065201ce6cfe$824201e0$86c605a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4XRSyzfZcZFbWGlfnEBogkVD1b5npQeKw Content-Language: en-gb Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:06:09 -0000 In case anyone should wonder... As one of the authors, I support this idea. I think it would be valuable to have this work pass through the working group to be modified and gain consensus. Adrian > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien > Meuric > Sent: 19 June 2013 14:38 > To: pce@ietf.org > Subject: [Pce] Poll for Adoption of draft-farrkingel-pce-questions > > Dear WG, > > Following the discussion about the future of the aforementioned document > and the feedback sent to the list, this message starts a poll for the > adoption of draft-farrkingel-pce-questions-03 by the PCE WG. > Pay attention to the document scope: the goal is _not_ to leave the I-D > open to gather all questions about PCE, but to store some useful text > associated to PCE by moving forward as an informational document. > > Please send your support/opposition to the PCE mailing list (the latter > typically requiring some explanation). Detailed comments on the I-D are > also welcome. > > Thanks, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From huaimo.chen@huawei.com Wed Jun 19 08:22:59 2013 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 3817B21F9C45 for ; Wed, 19 Jun 2013 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePOXeERnwdvg for ; Wed, 19 Jun 2013 08:22:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72DDF21F92E3 for ; Wed, 19 Jun 2013 08:22:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASP59625; Wed, 19 Jun 2013 15:22:50 +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.7; Wed, 19 Jun 2013 16:22:13 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 19 Jun 2013 16:22:45 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.169]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 19 Jun 2013 08:22:40 -0700 From: Huaimo Chen To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Thread-Index: AQHObPJHUjmjtshAhEyIT8Xkzf0mOpk9J6yw Date: Wed, 19 Jun 2013 15:22:39 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4451DFAE6@dfweml509-mbx.china.huawei.com> References: <51C1B43E.50605@orange.com> In-Reply-To: <51C1B43E.50605@orange.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions 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: Wed, 19 Jun 2013 15:22:59 -0000 Support! Best Regards, Huaimo -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julie= n Meuric Sent: Wednesday, June 19, 2013 9:38 AM To: pce@ietf.org Subject: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Dear WG, Following the discussion about the future of the aforementioned document an= d the feedback sent to the list, this message starts a poll for the adoptio= n of draft-farrkingel-pce-questions-03 by the PCE WG. Pay attention to the document scope: the goal is _not_ to leave the I-D ope= n to gather all questions about PCE, but to store some useful text associat= ed to PCE by moving forward as an informational document. Please send your support/opposition to the PCE mailing list (the latter typ= ically requiring some explanation). Detailed comments on the I-D are also w= elcome. Thanks, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From ina@juniper.net Wed Jun 19 08:51:29 2013 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 EFB5821F9C31 for ; Wed, 19 Jun 2013 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzsN702bE2US for ; Wed, 19 Jun 2013 08:51:24 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 848FB21F930C for ; Wed, 19 Jun 2013 08:51:21 -0700 (PDT) Received: from mail218-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 15:51:20 +0000 Received: from mail218-co1 (localhost [127.0.0.1]) by mail218-co1-R.bigfish.com (Postfix) with ESMTP id 87A518C033B for ; Wed, 19 Jun 2013 15:51:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail218-co1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=ina@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail218-co1 (localhost.localdomain [127.0.0.1]) by mail218-co1 (MessageSwitch) id 1371657077245349_14962; Wed, 19 Jun 2013 15:51:17 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.226]) by mail218-co1.bigfish.com (Postfix) with ESMTP id 3068F660089 for ; Wed, 19 Jun 2013 15:51:17 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 15:51:15 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Jun 2013 08:51:14 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Jun 2013 08:51:14 -0700 Received: from CO9EHSOBE021.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 09:03:12 -0700 Received: from mail55-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 15:51:12 +0000 Received: from mail55-co9 (localhost [127.0.0.1]) by mail55-co9-R.bigfish.com (Postfix) with ESMTP id 7BE75940225 for ; Wed, 19 Jun 2013 15:51:12 +0000 (UTC) Received: from mail55-co9 (localhost.localdomain [127.0.0.1]) by mail55-co9 (MessageSwitch) id 1371657071479178_22506; Wed, 19 Jun 2013 15:51:11 +0000 (UTC) Received: from CO9EHSMHS028.bigfish.com (unknown [10.236.132.238]) by mail55-co9.bigfish.com (Postfix) with ESMTP id 6E50FDC004C; Wed, 19 Jun 2013 15:51:11 +0000 (UTC) Received: from BLUPRD0511HT004.namprd05.prod.outlook.com (157.56.232.213) by CO9EHSMHS028.bigfish.com (10.236.130.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 15:51:08 +0000 Received: from BLUPRD0511MB436.namprd05.prod.outlook.com ([169.254.4.186]) by BLUPRD0511HT004.namprd05.prod.outlook.com ([10.255.135.167]) with mapi id 14.16.0324.000; Wed, 19 Jun 2013 15:51:06 +0000 From: Ina Minei To: Julien Meuric , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Thread-Index: AQHObPJX2CRkLA/LAEmEGU8cAvVsWJk9L5Eg Date: Wed, 19 Jun 2013 15:51:06 +0000 Message-ID: <70BDAD02381BA54CA31315A2A26A7AD3037F547A@BLUPRD0511MB436.namprd05.prod.outlook.com> References: <51C1B43E.50605@orange.com> In-Reply-To: <51C1B43E.50605@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions 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: Wed, 19 Jun 2013 15:51:30 -0000 Support. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julie= n Meuric Sent: Wednesday, June 19, 2013 6:38 AM To: pce@ietf.org Subject: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Dear WG, Following the discussion about the future of the aforementioned document an= d the feedback sent to the list, this message starts a poll for the adoptio= n of draft-farrkingel-pce-questions-03 by the PCE WG. Pay attention to the document scope: the goal is _not_ to leave the I-D ope= n to gather all questions about PCE, but to store some useful text associat= ed to PCE by moving forward as an informational document. Please send your support/opposition to the PCE mailing list (the latter typ= ically requiring some explanation). Detailed comments on the I-D are also w= elcome. Thanks, JP & Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From leeyoung@huawei.com Wed Jun 19 12:05:52 2013 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 60FDE21F9BB1 for ; Wed, 19 Jun 2013 12:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juz6jS9ALZ0p for ; Wed, 19 Jun 2013 12:05:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C812F21F8546 for

--047d7b417831e4709104dfaf4ef5-- From jmedved@cisco.com Fri Jun 21 13:11:52 2013 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 37D6E21F9AD2 for ; Fri, 21 Jun 2013 13:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvDVDYPfsPx3 for ; Fri, 21 Jun 2013 13:11:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB7F21F96EF for ; Fri, 21 Jun 2013 13:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4830; q=dns/txt; s=iport; t=1371845507; x=1373055107; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=9flF2wuQLJqjHZlCGqLogqEyJerClff5X4Bf54a0d6M=; b=jfRymvH1JXwj0ifF9Un5m9LwY+HV8eWWHA8bALXTvYxS/9SH7CpYkZF4 r7st3m/lR/GwvVFDIGd7ZC5kCdUEQ7l5gztu943n0vdgrAm13M5sX7AH6 LlXYq3weGkklsViCWATHo2UPMFjkO+TOPKqLIaArqBp3cLo5KO/h6qACU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALOyxFGtJV2Y/2dsb2JhbABbgkVEMUmtCpIqgQUWdIIlAQQBAQFrCxIBCAQKFB0uCxMBEQIEAQ0FCId0Aw8MvEEEjGSCNAYnBAeDAGEDlWCOA4Ukgw+CKA X-IronPort-AV: E=Sophos;i="4.87,915,1363132800"; d="scan'208,217";a="225947927" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 21 Jun 2013 20:11:46 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5LKBkKb018900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 20:11:46 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 15:11:46 -0500 From: "Jan Medved (jmedved)" To: Edward Crabbe , "Durga_uunet@yahoo.com" Thread-Topic: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Thread-Index: AQHObrf07lJ4Lfq0WkuL7WpJWFAB/JlAeCOA Date: Fri, 21 Jun 2013 20:11:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.155.66.109] Content-Type: multipart/alternative; boundary="_000_ACC8AB2D98C05F4E9FBDA092017D97FC152682E5xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions 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, 21 Jun 2013 20:11:52 -0000 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC152682E5xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 On 6/21/13 12:45 PM, "Edward Crabbe" = > wrote: Support. On Thu, Jun 20, 2013 at 3:19 AM, > wrote: Support. Brgds, Durgaprasad "DG" Gangisetti. On Jun 19, 2013, at 9:38 AM, Julien Meuric > wrote: Dear WG, Following the discussion about the future of the aforementioned document an= d the feedback sent to the list, this message starts a poll for the adoptio= n of draft-farrkingel-pce-questions-03 by the PCE WG. Pay attention to the document scope: the goal is _not_ to leave the I-D ope= n to gather all questions about PCE, but to store some useful text associat= ed to PCE by moving forward as an informational document. Please send your support/opposition to the PCE mailing list (the latter typ= ically requiring some explanation). Detailed comments on the I-D are also w= elcome. Thanks, JP & Julien _______________________________________________ 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 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC152682E5xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

On 6/21/13 12:45 PM, "Edward Crabbe" <edc@google.com> wrote:

Support.

On Thu, Jun 20, 2013 at 3:19 AM, <Durga_uun= et@yahoo.com> wrote:

Support.

Brgds, Durg= aprasad "DG" Gangisetti.

On Jun 19, 2013, at 9:38 AM, Julien Meuric <julien.meuric@orange.com> wrote:

Dear WG,

Following the discussion about the future of the aforementioned docum= ent and the feedback sent to the list, this message starts a poll for the a= doption of draft-farrkingel-pce-questions-03 by the PCE WG.
Pay attention to the document scope: the goal is _not_ to leave the I= -D open to gather all questions about PCE, but to store some useful text as= sociated to PCE by moving forward as an informational document.

Please send your support/opposition to the PCE mailing list (the latt= er typically requiring some explanation). Detailed comments on the I-D are = also welcome.

Thanks,

JP & Julien

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

--_000_ACC8AB2D98C05F4E9FBDA092017D97FC152682E5xmbalnx10ciscoc_-- From zali@cisco.com Fri Jun 21 13:37:04 2013 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 54F4021F9D17 for ; Fri, 21 Jun 2013 13:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTVMEXqeRvNT for ; Fri, 21 Jun 2013 13:36:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 65DC621F9CC1 for ; Fri, 21 Jun 2013 13:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2514; q=dns/txt; s=iport; t=1371847019; x=1373056619; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KfDkz4bgnGnWkkSG/FoTas2jg42nv3L+pC1lwSmtycI=; b=Q4PhvEpSL9aFd8Nudi25fLSnXuFZDKE7SNesML8dzIlTaXx00syfMpW3 T0oSCnLL+efzsb9r8DbNxH+2ZN9cj/KTVCFlZjY0Yx92qNDd1o3VGar/d WAhj1mvP6iYc4OMVr0xH6iNhBWFivw931NYRa0zXN3tkwCaNRTU8yxJhb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAFC4xFGtJV2d/2dsb2JhbABbgwkxSb81gQUWdIIjAQEBBAEBAWsLDAYBCBEDAQIBCksLHQgBAQQBDQUIiAYMvD0EjxgxBwaCemEDqQeDD4Io X-IronPort-AV: E=Sophos;i="4.87,915,1363132800"; d="scan'208";a="225933010" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jun 2013 20:36:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5LKawtg016543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 20:36:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 15:36:57 -0500 From: "Zafar Ali (zali)" To: Julien Meuric , "adrian@olddog.co.uk" Thread-Topic: [Pce] Next steps for draft-farrkingel-pce-questions Thread-Index: Ac5neOV6bpyH43/bTpiBxi1xkaK/TAEInRCAAMsFw4A= Date: Fri, 21 Jun 2013 20:36:57 +0000 Message-ID: In-Reply-To: <51BF2EAD.1000601@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.235.240] Content-Type: text/plain; charset="Windows-1252" Content-ID: <02B9C04504FE1047B4D79BCBA4ACBBDF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pce@ietf.org" Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions 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, 21 Jun 2013 20:37:04 -0000 Support!=20 Thanks Regards =8A Zafar -----Original Message----- From: "julien.meuric@orange.com" Organization: France Telecom Date: Monday, June 17, 2013 11:43 AM To: "adrian@olddog.co.uk" Cc: "pce@ietf.org" Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions >Hi all. > >As individual, I share the views expressed on the list: now that the I-D >exists, it would be a pity to let it die. Contrary to elephants, human >beings forget, so I would say: "go for an RFC!" > >Chair hat on, I thinks that: >- RFC errata is out of scope: it is supposed to be used for document >fixes, not updates; >- the choice between WG stream and individual streams remains in >authors' hands (just note that, based on the feedback seen on the list, >it would make sense to poll for WG adoption); >- I am not really comfortable with the option refered to as "publication >of the individual I-D under the care of the WG" because "under the care >of the WG" is not clear to me in that context; >- in any case, once published as an RFC, nothing prevents from >submitting a volume 2 later ("PCE FAQ: the pachyderm returns [for >peanuts]"). > >Regards, > >Julien > > >On 06/12/2013 16:27, Adrian Farrel wrote: >> Hi chairs and working group, >> >> Dan and I are wondering what to do with this draft. >> >> It seems that a number of people have been reading it and have found it >>useful >> or at least stimulating. >> >> At the moment, it represents just the rambling thoughts of two >>individuals, so >> my question is really whether the WG thinks this would be something >>that could >> be usefully published as an RFC or should be judged to have served its >>purpose >> now and allowed to die. >> >> If published as an RFC there would be a number of ways to go forward: >>adoption >> by the WG and subsequent edits; publication of the individual I-D under >>the care >> of the WG (still review and edit, but faster); publication as an >>individual I-D >> (under the care of an AD with review by the PCE working group). >> >> We'd be interested to know what you think before we decide what action >>to >> request for the document. >> >> And, of course, any issues or thoughts on the document would be very >>welcome. >> >> Thanks, >> Adrian >> >> >> > >_______________________________________________ >Pce mailing list >Pce@ietf.org >https://www.ietf.org/mailman/listinfo/pce From jvasseur@cisco.com Sat Jun 22 01:20:02 2013 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 72D9C21F9CA8 for ; Sat, 22 Jun 2013 01:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ERtgScORi4N for ; Sat, 22 Jun 2013 01:19:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D510021F9D92 for ; Sat, 22 Jun 2013 01:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2966; q=dns/txt; s=iport; t=1371889196; x=1373098796; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lDIDIH4Up1R2uQBwOhQvS3u3uNomdcHKxuJCPBJ1Fqk=; b=NJS4SFo1Uacw1gfTv8cjtlFNCrcd3URIgAgsBCTQyy6HqwdwMDNHAIGg QsOwezkZZcC1YcBwIKCHIJky56niAHopEdULF4pCe6hOTByxPPHiq2amg 6NIFYCAJirKVq2S1XcSVpkXJH5HoK+47uHpS+y4EMFqzmNc07mk+jNRFF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAJBdxVGtJV2Z/2dsb2JhbABbgkVEeoI8vH5/FnSCJAEBBHkQAgEIBB4kMiUCBAENDYgGvDCPGDEHgwBhA6kHgw+CKA X-IronPort-AV: E=Sophos;i="4.87,917,1363132800"; d="scan'208,217";a="226075807" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jun 2013 08:19:51 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5M8JoDT002668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jun 2013 08:19:50 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.110]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sat, 22 Jun 2013 03:19:50 -0500 From: "JP Vasseur (jvasseur)" To: Ina Minei , "pce@ietf.org" Thread-Topic: Stateful PCE applicability Thread-Index: AQHObyFDJgXNfL1E2Ua4cIjIQL9O4g== Date: Sat, 22 Jun 2013 08:19:49 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77235C3D6B@xmb-rcd-x02.cisco.com> References: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> In-Reply-To: <70BDAD02381BA54CA31315A2A26A7AD3037F6021@BLUPRD0511MB436.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.226] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77235C3D6Bxmbrcdx02ciscoc_" MIME-Version: 1.0 Subject: Re: [Pce] Stateful PCE applicability 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: Sat, 22 Jun 2013 08:20:02 -0000 --_000_03B78081B371D44390ED6E7BADBB4A77235C3D6Bxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ina - good question : WG, please voice your opinion Thanks JP. On Jun 21, 2013, at 9:16 AM, Ina Minei wrote: Dear chairs and working group, In light of the recent working group re-charter which now includes stateful= PCE, we wanted to hear the opinions of the group on 1. the need for an applicability document for stateful PCE and 1. whether draft-zhang-pce-stateful-pce-app satisfies this need, or any = gaps it might have Thank you, Ina and Xian --_000_03B78081B371D44390ED6E7BADBB4A77235C3D6Bxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0E52712E5F9ADD4A957073701F32DBB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Thanks Ina - good question : WG, please voice your opinion

Thanks JP.

On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:

Dear chairs and working group,

In light of the recent working group re-charter which now includes sta= teful PCE, we wanted to hear the opinions of the group on

the need for an applicability document for stateful PCE and

whether draft-zhang-pce-stateful-pce-app satisfies this need, or any ga= ps it might have

Thank you,

Ina and Xian

--_000_03B78081B371D44390ED6E7BADBB4A77235C3D6Bxmbrcdx02ciscoc_-- From zhang.xian@huawei.com Mon Jun 24 02:26:22 2013 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 3384921F969F for ; Mon, 24 Jun 2013 02:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPF63lPxj6YK for ; Mon, 24 Jun 2013 02:26:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 893F921E809F for ; Mon, 24 Jun 2013 02:26:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUH28562; Mon, 24 Jun 2013 09:26:13 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 10:25:34 +0100 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 17:26:11 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 17:25:53 +0800 From: "Zhangxian (Xian)" To: "adrian@olddog.co.uk" , "'Julien Meuric'" , "pce@ietf.org" Thread-Topic: [Pce] Poll for Adoption of draft-farrkingel-pce-questions Thread-Index: AQHObPJDMlQvLbV9O02Fgztgg1AquZk8nP2AgAE1a9A= Date: Mon, 24 Jun 2013 09:25:52 +0000 Message-ID: References: <51C1B43E.50605@orange.com> <065201ce6cfe$824201e0$86c605a0$@olddog.co.uk> In-Reply-To: <065201ce6cfe$824201e0$86c605a0$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] Poll for Adoption of draft-farrkingel-pce-questions 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, 24 Jun 2013 09:26:22 -0000 SGksIEFkcmlhbiBhbmQgQWxsLCANCg0KICAgSSBzdXBwb3J0IHRoaXMuIEFzIHN0YXRlZCBpbiB0 aGUgYmVnaW5uaW5nIG9mIHRoZSBkcmFmdCwgaXQgZG9lcyBmaWxsIHRoZSBnYXAgZm9yIG5ldyBj b21lcnMgdG8gYXZvaWQgdGhpbmdzIGxpa2UgIm1pc3NlZCBvdXQgb24gZWFybHkgZGlzY3Vzc2lv bnMgd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwIGFuZCBhcmUgdW5mYW1pbGlhciB3aXRoDQogICBx dWVzdGlvbnMgdGhhdCB3ZXJlIHJhaXNlZCBkdXJpbmcgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBk b2N1bWVudGF0aW9uLiIuIA0KDQogICBNb3Jlb3ZlciwgSSBhbHNvIHVzZSB0aGUgZHJhZnQgdG8g dW5kZXJzdGFuZCBjdXJyZW50IGhvdCB0b3BpY3MvZHJhZnRzLiBTbywgc2V2ZXJhbCBwb2ludHMg SSB3b3VsZCBsaWtlIHRvIHJhaXNlL2Rpc2N1c3MgaGVyZSwgaG9wZSB0aGlzIGhlbHBzIGZvciB0 aGUgZHJhZnQgdXBkYXRlOiANCg0KMTogSSBhbSBhd2FyZSB0aGlzIGRyYWZ0IGRvZXMgbm90IGlu dGVuZCB0byBjb3ZlciAiZXZlcnkgcXVlc3Rpb24iLiBIb3dldmVyLCBpdCBzaG91bGQgYXQgbGVh c3QgYWRkcmVzcyB0b3BpY3MgdW5kZXIgYWN0aXZlIGRpc2N1c3Npb25zLiBTbywgSSB3b25kZXIg d2hldGhlciB0aGUgZHJhZnQgc2hvdWxkIGFsc28gY2FwdHVyZSB0aGUgdG9waWMgb2Ygb3Zlcmxh eSwgaS5lLiB1c2luZyBQQ0UgZm9yIHRoZSBzY2VuYXJpb3Mgd2hlcmUgVU5JL09OSSg/KSBpcyBw cmVzZW50LCB3aGljaCB0aGVyZSBhcmUgYWxyZWFkeSBzZXZlcmFsIGRyYWZ0cyBpbiBDQ0FNUCBX RywgaWYgcmVsYXRlZCBpc3N1ZXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZT8gU3VjaCBhczog aG93IHRvIGRpc2NvdmVyIHRoZSBVTkkvT05JIGludGVyZmFjZXMgaWYgUENFIGlzIHVzZWQgaW4g dGhpcyBjb250ZXh0PyBXaGV0aGVyIEgtUENFIGlzIGhlbHBmdWw/IGV0Yy4gSSBhbSBub3Qgc3Vy ZSB3aGljaCBzZWN0aW9ucyBhcmUgcmVsZXZhbnQgZXhhY3RseS4gTWF5YmUgU2VjdGlvbiAzLCA0 PyBNYXliZSBzb21lIHNpbXBsZSBleHBsYW5hdGlvbnMgcGx1cyBhIHJlZmVyZW5jZSB0byB0aGUg cmVsZXZhbnQgSS1EIGRyYWZ0KHMpIHdvdWxkIHN1ZmZpY2UuDQoNCjI6IEluIFNlY3Rpb24gMywg aXQgc3RhdGVzICJOb3RlIHRoYXQgdGhpcyBleGNoYW5nZSBvZiBQQ0UgY2FwYWJpbGl0aWVzIGlz IGluIHRoZSBmb3JtIG9mIGFuDQogICBhbm5vdW5jZW1lbnQsIG5vdCBhIG5lZ290aWF0aW9uLiAg VGhhdCBpcywgYSBQQ0MgdGhhdCB3YW50cyBzcGVjaWZpYw0KICAgZnVuY3Rpb24gZnJvbSBhIFBD RSBtdXN0IGV4YW1pbmUgdGhlIGFkdmVydGlzZWQgY2FwYWJpbGl0aWVzIGFuZA0KICAgc2VsZWN0 IHdoaWNoIFBDRSB0byB1c2UgZm9yIGEgc3BlY2lmaWMgcmVxdWVzdC4gIFRoZXJlIGlzIG5vIHNj b3BlDQogICBmb3IgYSBQQ0MgdG8gcmVxdWVzdCBhIFBDRSB0byBzdXBwb3J0IGZlYXR1cmVzIG9y IGZ1bmN0aW9ucyB0aGF0IGl0DQogICBkb2VzIG5vdCBvZmZlciBvciBhbm5vdW5jZS4iDQoNCkZy b20gd2hhdCB3ZSBjdXJyZW50bHkgaGF2ZSBpbiBTZWN0aW9uIDUuMyBvZiBkcmFmdCAtaWV0Zi1w Y2Utc3RhdGVmdWwtcGNlLTA0LCBpdCBzZWVtcyB0byBtZSB0aGF0IExTUCBtb2RpZmljYXRpb24g Y2FwYWJpbGl0eSBpcyBuZWdvdGlhdGVkICpub3QqIGFkdmVydGlzZWQuIFRoZSByZWFzb24gaXMg b2J2aW91cyBzaW5jZSBpdCBpcyBhIHR3by13YXkgdGhpbmcuIEp1c3Qgd29uZGVyIHdoZXRoZXIg cGhyYXNlIGxpa2VzICJzdGF0ZWZ1bCBQQ0UgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiIgaW4gdGhl IFdHIGRyYWZ0IG9yIHRoZSB0ZXh0IGFib3ZlIHNob3VsZCBiZSBtb2RpZmllZCB0byBhdm9pZCBj b25mdXNpb24/IA0KDQozOiBTZWN0aW9uIDE4LCBpdCBzdGF0ZXMgIkxTUCBkZWxlZ2F0aW9uIFtJ LUQuaWV0Zi1wY2Utc3RhdGVmdWwtcGNlXSBpcyB0aGUgcHJvY2VzcyB3aGVyZSBhIFBDQw0KICAg KHVzdWFsbHkgYW4gaW5ncmVzcyBMU1IpIHBhc3NlcyByZXNwb25zaWJpbGl0eSBmb3IgdHJpZ2dl cmluZw0KICAgcmVvcHRpbWl6YXRpb24gb3IgcmUtcm91dGluZyBvZiBhbiBMU1AgdG8gdGhlIFBD RS4iDQoNCkxTUCBkZWxlZ2F0aW9uIGNvdmVycyB3aWRlciBwdXJwb3NlIHRoYW4gc3RhdGVkIGFi b3ZlLCByaWdodD8gRm9yIGV4YW1wbGUgcHJvdmlkaW5nIHByb3RlY3Rpb24gcGF0aHMsIGFzIGRl c2NyaWJlZCBpbiBkcmFmdCAtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLTAwLiANCg0KNDogU2VjdGlv biAyMTogQnkgbG9va2luZyBhdCB0aGUgbGFzdCBwYXJhZ3JhcGgsIGVzcGVjaWFsbHkgdGhlIGxh c3Qgc2VudGVuY2UsIGNhbiBJIGludGVycHJldCBpdCBhcyAiRm9yIHRoZSBzaW5nbGUgUENFIG1v ZGVsIHdoZXJlIG9uZSBQQ0UgY29udHJvbHMgbXVsdGlwbGUgbGF5ZXJzLCBnaXZlbiB0aGUgUENF IGlzIGFjdGl2ZSBzdGF0ZWZ1bCwgdGhpcyBQQ0UgcGVyZm9ybXMgdGhlIGZ1bmN0aW9uIG9mIHBh dGggY29tcHV0YXRpb24gYW5kIHRyaWdnZXJpbmcgb2YgTFNQIHNldHVwKFZOTVQgZnVuY3Rpb24p Ij8gSWYgc28sIHNlZW1zIHRoZXJlIGlzIG5vIG5lZWQgZm9yIFZOVE0gaW4gdGhpcyBtb2RlbCBh bmQgdGh1cyB0aGUgZXhwbGFuYXRpb24gaW4gU2VjdGlvbiAyMiBpcyBub3QgYXBwbGljYWJsZS4g SSBzdWdnZXN0IHRvIGdpdmUgdGhlIHR5cGUgb2YgUENFIHlvdSBhcmUgdXNpbmcgZm9yIHRoZSBl eHBsYW5hdGlvbiwgaXQgd291bGQgbWFrZSB0aGluZ3MgY2xlYXJlci4gDQoNCjU6IFNlY3Rpb24g MjQgd3JpdGVzOiAiIC0gQW4gQWN0aXZlIFBDRSBtdXN0IGhhdmUgYSBwb2xpY3kgcmVsYXRpb25z aGlwIHdpdGggaXRzIExTUnMgdG8NCiAgICAgZGV0ZXJtaW5lIHdoaWNoIExTUHMgY2FuIGJlIG1v ZGlmaWVkIG9yIHRyaWdnZXJlZCwgYW5kIHdoYXQgTFNQDQogICAgIGRlbGVnYXRpb24gaXMgc3Vw cG9ydGVkLiINCg0KRG9lcyBpdCBtZWFuIHRoZSBhY3RpdmUgY2FwYWJpbGl0eSBvZiBhIFBDRSBp cyBjb25maWd1cmVkIG9uIGEgcGVyLW5vZGUgYmFzZWQsIG9yIGV2ZW4gcGVyIExTUCBiYXNlZD8g VGhpcyBzZWVtcyB0byBiZSBhIGJpdCB0b28gY29tcGxpY2F0ZWQgYW5kIG5vdCBwcmFjdGljYWwu IERvZXMgaXQgbWFrZSBzZW5zZSB0byBzYXkgTFNScyBzaG91bGQgaGF2ZSB0aGUgbG9jYWwgcG9s aWN5IHRvIGRlY2lkZSB3aGV0aGVyIHRvIGRlbGVnYXRlIGEgTFNQIGFuZCB3aGF0IHBhcmFtZXRl cnMgaXMgYWxsb3dlZCB0byBtb2RpZnk/IERpZmZlcmVudCBmcm9tIHRoZSBzdGF0ZW1lbnQgYWJv dmUsIGl0IGRvZXMgbm90IG5lZWQgUENFIHRvIGFncmVlL25lZ290aWF0ZS4gTWF5YmUgdGhhdCBp cyBleGFjdGx5IHdoYXQgdGhlIGFib3ZlIHNlbnRlbmNlIHdhbnRzIHRvIHNheSwgYnV0IGZvciBu b3cgaXQgaXMgbm90IGNsZWFyIHRvIG1lLiANCg0KUmVnYXJkcywNClhpYW4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQpTZW50OiAyMDEz xOo21MIxOcjVIDIzOjA2DQpUbzogJ0p1bGllbiBNZXVyaWMnOyBwY2VAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbUGNlXSBQb2xsIGZvciBBZG9wdGlvbiBvZiBkcmFmdC1mYXJya2luZ2VsLXBjZS1x dWVzdGlvbnMNCg0KSW4gY2FzZSBhbnlvbmUgc2hvdWxkIHdvbmRlci4uLg0KDQpBcyBvbmUgb2Yg dGhlIGF1dGhvcnMsIEkgc3VwcG9ydCB0aGlzIGlkZWEuIEkgdGhpbmsgaXQgd291bGQgYmUgdmFs dWFibGUgdG8gaGF2ZQ0KdGhpcyB3b3JrIHBhc3MgdGhyb3VnaCB0aGUgd29ya2luZyBncm91cCB0 byBiZSBtb2RpZmllZCBhbmQgZ2FpbiBjb25zZW5zdXMuDQoNCkFkcmlhbg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHBjZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWxpZW4NCj4gTWV1cmljDQo+IFNl bnQ6IDE5IEp1bmUgMjAxMyAxNDozOA0KPiBUbzogcGNlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtQ Y2VdIFBvbGwgZm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWZhcnJraW5nZWwtcGNlLXF1ZXN0aW9ucw0K PiANCj4gRGVhciBXRywNCj4gDQo+IEZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGUg ZnV0dXJlIG9mIHRoZSBhZm9yZW1lbnRpb25lZCBkb2N1bWVudA0KPiBhbmQgdGhlIGZlZWRiYWNr IHNlbnQgdG8gdGhlIGxpc3QsIHRoaXMgbWVzc2FnZSBzdGFydHMgYSBwb2xsIGZvciB0aGUNCj4g YWRvcHRpb24gb2YgZHJhZnQtZmFycmtpbmdlbC1wY2UtcXVlc3Rpb25zLTAzIGJ5IHRoZSBQQ0Ug V0cuDQo+IFBheSBhdHRlbnRpb24gdG8gdGhlIGRvY3VtZW50IHNjb3BlOiB0aGUgZ29hbCBpcyBf bm90XyB0byBsZWF2ZSB0aGUgSS1EDQo+IG9wZW4gdG8gZ2F0aGVyIGFsbCBxdWVzdGlvbnMgYWJv dXQgUENFLCBidXQgdG8gc3RvcmUgc29tZSB1c2VmdWwgdGV4dA0KPiBhc3NvY2lhdGVkIHRvIFBD RSBieSBtb3ZpbmcgZm9yd2FyZCBhcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KPiANCj4g UGxlYXNlIHNlbmQgeW91ciBzdXBwb3J0L29wcG9zaXRpb24gdG8gdGhlIFBDRSBtYWlsaW5nIGxp c3QgKHRoZSBsYXR0ZXINCj4gdHlwaWNhbGx5IHJlcXVpcmluZyBzb21lIGV4cGxhbmF0aW9uKS4g RGV0YWlsZWQgY29tbWVudHMgb24gdGhlIEktRCBhcmUNCj4gYWxzbyB3ZWxjb21lLg0KPiANCj4g VGhhbmtzLA0KPiANCj4gSlAgJiBKdWxpZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBjZSBtYWlsaW5nIGxpc3QNCj4gUGNlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQY2UgbWFpbGluZyBs aXN0DQpQY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGNlDQo= From julien.meuric@orange.com Mon Jun 24 09:32:07 2013 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 44A8A21F9BB4 for ; Mon, 24 Jun 2013 09:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27J3rx8IhZLD for ; Mon, 24 Jun 2013 09:32:03 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id C1B9721F9A3F for ; Mon, 24 Jun 2013 09:32:02 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 43219E300B5 for ; Mon, 24 Jun 2013 18:32:37 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 3C9A1E300B4 for ; Mon, 24 Jun 2013 18:32:37 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jun 2013 18:32:01 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jun 2013 18:32:01 +0200 Message-ID: <51C8747F.50604@orange.com> Date: Mon, 24 Jun 2013 18:31:59 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: pce@ietf.org References: <51B82C91.3050304@orange.com> In-Reply-To: <51B82C91.3050304@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Jun 2013 16:32:01.0289 (UTC) FILETIME=[5A806F90:01CE70F8] Subject: Re: [Pce] WG Last Call of draft-ietf-pce-vendor-constraints-10 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, 24 Jun 2013 16:32:07 -0000 Hi all. The I-D is not particularly long and is certainly well-known by many of you: a few reviews would be much appreciated. Thanks, JP & Julien Le 12/06/2013 10:08, Julien Meuric a �crit : > Hi PCE'rs. > > This message ignites a 2-week-long WG last call for > draft-ietf-pce-vendor-constraints-10. Please send your comments on the > I-D to the PCE mailing list by Wednesday June 26. > > Best regards, > > JP & Julien > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > From julien.meuric@orange.com Tue Jun 25 06:44:38 2013 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 5413921E8090 for ; Tue, 25 Jun 2013 06:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDcH-RtvKJLR for ; Tue, 25 Jun 2013 06:44:34 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id B74E51F0D1B for ; Tue, 25 Jun 2013 06:44:30 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 992395D8884 for ; Tue, 25 Jun 2013 15:44:28 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 8E9435D8870 for ; Tue, 25 Jun 2013 15:44:28 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jun 2013 15:44:28 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jun 2013 15:44:28 +0200 Message-ID: <51C99EBB.7050709@orange.com> Date: Tue, 25 Jun 2013 15:44:27 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pce@ietf.org" References: <51C46587.3020907@cisco.com> In-Reply-To: <51C46587.3020907@cisco.com> X-Forwarded-Message-Id: <51C46587.3020907@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Jun 2013 13:44:28.0546 (UTC) FILETIME=[1D035620:01CE71AA] Subject: [Pce] Fwd: [mpls] Fwd: Status BOF in Berlin 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: Tue, 25 Jun 2013 13:44:38 -0000 Hi all. The PCE WG has not been flagged as directly impacted, but the following BoF remains of high interest for PCE in packet networks. Julien -------- Message original -------- Date : Fri, 21 Jun 2013 15:39:03 +0100 De : Stewart Bryant This BOF touches on technology of interest to each of the working groups on the "To" list. I apologies to those that have already seen this through circulation to routing-discussion, but I know that not everyone is subscribed there. The list for discussion of this topic is status@ietf.org - Stewart -------- Original Message -------- Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant STATUS * Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS] * Status: Approved * Description The IETF has two packet-based forwarding technologies: IP and MPLS. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940 ) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6. This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic. * Responsible Area Directors: Adrian Farrel and Stewart Bryant * BoF Chairs: Alvaro Retana, John Scudder * * Mailing list: https://www.ietf.org/mailman/listinfo/status Further details can be found at http://trac.tools.ietf.org/bof/trac/wiki - Stewart From adrian@olddog.co.uk Tue Jun 25 10:21:47 2013 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 068BB11E812F for ; Tue, 25 Jun 2013 10:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY3-qzZkL0Lm for ; Tue, 25 Jun 2013 10:21:42 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 92B4921F9A86 for ; Tue, 25 Jun 2013 10:21:39 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5PHLbGR023127; Tue, 25 Jun 2013 18:21:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5PHLXZY023006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 18:21:37 +0100 From: "Adrian Farrel" To: "'Julien Meuric'" ,