From nobody Tue Nov 1 01:54:31 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C51C12940C; Tue, 1 Nov 2016 01:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLxibdi5Qgjk; Tue, 1 Nov 2016 01:54:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2806129556; Tue, 1 Nov 2016 01:54:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZL76441; Tue, 01 Nov 2016 08:54:22 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 08:54:04 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.175]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 16:53:43 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , Greg Mirsky Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-flow-ident Thread-Index: AQHSLB2CbRR4SR9pTUuevvnYK9hyLKC21SyAgABkx4CAAAJ0AIAMpdcg Date: Tue, 1 Nov 2016 08:53:43 +0000 Message-ID: References: <4d64aaea-9d3d-e391-24c7-b294fed95716@gmail.com>, <7E688250-218F-477F-955B-E1BA843140F6@cisco.com> In-Reply-To: <7E688250-218F-477F-955B-E1BA843140F6@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F29F232SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5818583F.014C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1259e9935345b3c7f763b0f760074380 Archived-At: Cc: "draft-ietf-mpls-flow-ident@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-flow-ident X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 08:54:29 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F29F232SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ditto. Best regards, Mach From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Monday, October 24, 2016 11:44 PM To: Greg Mirsky Cc: Loa Andersson; mpls@ietf.org; mpls-chairs@ietf.org; draft-ietf-mpls-flo= w-ident@ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-flow-ident Ditto. I know of no IPR applicable directly to this document. I know there is disc= losed IPR against solutions. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Oct 24, 2016, at 08:34, Greg Mirsky > wrote: Dear All, I'm not aware of any IPR other than mentioned by Stewart. Regards, Greg On Mon, Oct 24, 2016 at 2:34 AM, Stewart Bryant > wrote: There is IPR on the SL work which follows on from this (already declared ag= ainst those documents). This text calls up draft-tempia-ippm-p3m-03 which has IPR, whether it need= s to be formally declared I leave to the chairs to decide. I know of no other IPR that relates directly to this document. Stewart On 22/10/2016 05:33, Loa Andersson wrote: Working Group, We are currently preparing draft-ietf-mpls-flow-ident-02 for working group last call. We will do an IPR poll prior to the wglc. This is to start the IPR Poll. Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is no IPR disclosure filed directly against this documents. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F29F232SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ditto.

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Monday, October 24, 2016 11:44 PM
To: Greg Mirsky
Cc: Loa Andersson; mpls@ietf.org; mpls-chairs@ietf.org; draft-ietf-m= pls-flow-ident@ietf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-flow-ident

 

Ditto.

 

I know of no IPR applicable dir= ectly to this document. I know there is disclosed IPR against solutions.&nb= sp;


Thumb typed by Carlos Pignataro.

Excuze typofraphicak errows=

=
On Oct 24, 2016, at 08:34, Greg Mirsky <gregimirsky@gmail.com> wrote:

Dear All,

I'm not aware of any IPR other = than mentioned by Stewart.

 

Regards,

Greg

 

On Mon, Oct 24, 2016 at 2:34 AM= , Stewart Bryant <stewart.bryant@gmail.com> wrote:

There is IPR on the SL work whi= ch follows on from this (already declared against those documents).

This text calls up  draft-tempia-ippm-p3m-03 which has IPR, whether it= needs to be formally declared I leave to the chairs to decide.

I know of no other IPR that relates directly to this document.

Stewart



On 22/10/2016 05:33, Loa Andersson wrote:
<= span class=3D"im">

= Working Group,

We are currently preparing draft-ietf-mpls-flow-ident-02 for working
group last call. We will do an IPR poll prior to the wglc.

This is to start the IPR Poll.

Are you aware of any IPR that applies to draft-ietf-mpls-flow-ident?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There is no IPR disclosure filed directly against this documents.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

/Loa
mpls wg co-chair

 

_______________________________= ________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28F29F232SZXEMA510MBXchi_-- From nobody Thu Nov 3 02:13:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C300129766; Thu, 3 Nov 2016 02:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dre0XUCLhiae; Thu, 3 Nov 2016 02:13:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6299129715; Thu, 3 Nov 2016 02:13:17 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-43-581affac493c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id B9.AA.07742.CAFFA185; Thu, 3 Nov 2016 10:13:16 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 10:13:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+79ftig/ujgjrcK+WiWqe76nEHmV16mdHEjPxPDvGIk=; b=ceEgCxkd6f66W8XUnRRQCU7zXBy3HSjM4omI/tkMQHmsVj7tGCPaz3lDNdtwfLf+43evvpmt9U89HxEaSLFj/EfPL8gA8l1ydRQGM0u0IzFaI/NiH/8GXL70rzC6rS6aU9+PReyyll9Ag4LzK0Gj5SwNNMC7s+04iemrJ7iny9U= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0995.eurprd07.prod.outlook.com (10.162.37.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 09:13:15 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 09:13:14 +0000 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: CCAMP and JOINT YANG session agenda @IETF97 Thread-Index: AdI1sl00KIv6ZxVIScKzfSr4Zs2Uog== Date: Thu, 3 Nov 2016 09:13:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 318452b4-06a0-46ac-6700-08d403c9a465 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0995; 7:04Ql8vYFMwnCHibYMTQkm/W+SPg45z3R2plFOOjaUKgpNBwIp9rsWNYh8tMRcuE1EPCvbrFnFXQTnLzywmYQ5fAu8Umbq+sj1blF6AyFUxBql93r+5WE3HXTNc9PFfqZi0SQqwQa7GBLCCj2rIigCeW4t6TVrxJWvQ25DDg3I5ndgx3YlYWkJCpJ9efXASgDPYSF4R5eCdqWaYqDcNtS2MCdHlE7Fhk0A7UpKbhUwldHKSWpHhQTNLn6pmuuVPoC2LCRGsiaBBarxs8oZfRVCmarPYhr0iDdM3kcBrC3PJDBekcmhcjF5F+SFkxV5YcGj/Sf2wzxCWUCzRqNtJEeJjI8/B/b1j2HF1bdX0KypLI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0995; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0995; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0995; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(53754006)(189002)(76576001)(122556002)(3660700001)(105586002)(97736004)(229853001)(87936001)(9686002)(7696004)(5660300001)(106356001)(5001770100001)(5002640100001)(19617315012)(558084003)(86362001)(101416001)(19580395003)(10400500002)(3280700002)(8936002)(50986999)(66066001)(107886002)(189998001)(33656002)(19625215002)(586003)(68736007)(54356999)(16236675004)(77096005)(8676002)(15975445007)(450100001)(2906002)(790700001)(6116002)(3846002)(102836003)(74316002)(81156014)(81166006)(19300405004)(7736002)(7846002)(2501003)(2900100001)(7906003)(92566002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0995; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 09:13:14.6140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0995 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+e3ebXerwc8587Rp6MrezUqJKdELyiCLoqAhUc28OHNO3TVJ IZiSYaPIV6jLcDLNRz4iFEdv18NMy0wzsdaYD7IsAivUNM3rneB/n3O+38M5XzgUIa3ny6k4 QwptNGj1SoGYLNY0r9lUOyvXbO4a8VIPlfSR6v6Kar4609UnVGdN2Mld5P7y8kneYRQl3h5D 6+NSaWPwjtNiXV722qTrivOFRa2kCdnAjEQU4FCY7RggzEhMSXE9grEmm6doRfCz0y5kCxJf JeBSZi2PU/J5kGF2kVzxHMFwY/vcDEUJcDgMOSLZvgxbEPxruilkl3izSx71INYjw2HwtN/A tmVYBS+vdJEsk3gVZEya5lmCT8Dka9v8KMLLYPwVu1hEEdgX+odKedzdGMofdBIc+8DXwRk+ 54+Ghiy7xxMIb2ssHj4IN95VIfY2wFYC/jiHPcI+uOae8HA8NPUWCDgOh+zcVj43YEeQOV6E OMEPqtqGBZyQIQDzlzvzZ0sxDZV1WYhLLAdnz2UP+8HIp4d8LkIiPGsa8MT0grbiITIHrbYs SmdZZLMssnH9jWC9PybgeAPcKhslFrjjySBvcd+KhDXIh6GZ6ITYrSEq2hh3hmESDSoDnXIX zX1RS+NUkB11f9/tQJhCyqWSpNnlGilfm8qkJTgQUIRSJimakWukkhhtWjptTDxlPKenGQdS UKTSV7Kt2nVcimO1KXQ8TSfRxgWVR4nkJiT/9aHRLrut+5tT4vT+diQi0dTy24rt4Q1pBen+ udP5yXvpJffWtdiiuoJ1Ky401KzUK+rUH0fMoYdOqvSKCr9g/973YS5T1kX3lDvCeTRyz868 5hpV8o/pqoDM9rLC7hfpjs9n34w+PhCQH+jNjziGQhpK3UylUzwpDhINtDYrSUan3bKeMDLa /3RePOJBAwAA Archived-At: Subject: [mpls] CCAMP and JOINT YANG session agenda @IETF97 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:13:26 -0000 --_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, the first version of the agenda for the CCAMP session and the Joint YANG se= ssion is available at the following link. https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01 Please let us have your comments Thanks MPLS, PCE, TEAS and CCAMP (chairs and secretaries) --_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

the first version of the agenda= for the CCAMP session and the Joint YANG session is available at the follo= wing link.

 

https://www.ietf.org/proceedings= /97/agenda/agenda-97-ccamp-01

 

Please let us have your comment= s

 

Thanks

MPLS, PCE, TEAS and CCAMP (chai= rs and secretaries)

--_000_AM2PR07MB09943987D6E27931F8C7CF3EF0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 06:15:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10D2129552; Thu, 3 Nov 2016 06:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD3ZzVziRcbK; Thu, 3 Nov 2016 06:15:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4CC1288B8; Thu, 3 Nov 2016 06:15:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZP79636; Thu, 03 Nov 2016 13:15:08 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 13:15:05 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 06:15:00 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: draft-zhang-ccamp-transport-yang-gap-analysis-01 Thread-Index: AQHSNdRH8wTxiplTbUanpuZ0BVNtuQ== Date: Thu, 3 Nov 2016 13:15:00 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581B385D.0137, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 59cd424c08fea7caa8e897acb20a402a Archived-At: Subject: [mpls] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:15:16 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the 4.4. Function Summary and Related YANG Models, I rea= d: +-------------+-----------------------+-----------------------+ |Path Comp. | Path Computation pre | | | | service provisioning | NONE | +-------------+-----------------------+-----------------------+ I disagree with this assessment. TE tunnel model defines the COMPUTE_ONLY m= ode explicitly designed to be used to support Path computation NBI. Cheers, Igor From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Thursday, November 03, 2016 5:13 AM To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@iet= f.org Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97 Hi all, the first version of the agenda for the CCAMP session and the Joint YANG se= ssion is available at the following link. https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01 Please let us have your comments Thanks MPLS, PCE, TEAS and CCAMP (chairs and secretaries) --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

In the 4.4.  Function Su= mmary and Related YANG Models, I read:

 

+-------------+-----------------------&= #43;-----------------------+

        = ; |Path Comp.   | Path Computation pre  |   &= nbsp;           &nbs= p;       |

        = ; |             = ;| service provisioning  |      NONE &nb= sp;           |

        = ; +-------------+-----------------------+----------------------= -+

 

I disagree with thi= s assessment. TE tunnel model defines the COMPUTE_ONLY mode explicitly desi= gned to be used  to support Path computation NBI.

 

Cheers,<= /span>

Igor

 

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); m= pls@ietf.org
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

 

Hi all,

 

the first version of the agenda for the CCAMP sessio= n and the Joint YANG session is available at the following link.=

 

https://www.ietf.org/proceedings/97/agenda/agenda-97-= ccamp-01

 

Please let us have your comments

 

Thanks

MPLS, PCE, TEAS and CCAMP (chairs and secretaries)

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF03dfweml501mbx_-- From nobody Thu Nov 3 06:35:14 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD91295D0; Thu, 3 Nov 2016 06:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE9MlkbZRE0Y; Thu, 3 Nov 2016 06:35:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880E11299CD; Thu, 3 Nov 2016 06:35:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL31645; Thu, 03 Nov 2016 13:35:02 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 13:34:11 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 06:34:05 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uQ== Date: Thu, 3 Nov 2016 13:34:04 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.581B3D07.045A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 528c19965a08031a827385632939270e Archived-At: Subject: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:35:09 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF32dfweml501mbx_-- From nobody Thu Nov 3 06:37:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FF21299E4; Thu, 3 Nov 2016 06:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkSzwzzBS2A0; Thu, 3 Nov 2016 06:37:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FF81299E5; Thu, 3 Nov 2016 06:37:19 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 256112E3F227D; Thu, 3 Nov 2016 13:37:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3DbF1a022116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 13:37:17 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3Da2vL020937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 14:37:12 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.62]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 14:36:22 +0100 From: "Belotti, Sergio (Nokia - IT)" To: Igor Bryskin , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 Thread-Index: AQHSNdRYPr/r9zO8ikuUMQHj9hfS3aDHQPzw Date: Thu, 3 Nov 2016 13:36:21 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: "Sharma, Anurag 6. \(EXT - IN\)" Subject: Re: [mpls] [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:37:35 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Igor, you probably have an older version: +-------------+-----------------------+---------------------------+ |Path Comp. | Path Computation pre | = | | | service provisioning | ietf-te.yang = | +-------------+-----------------------+------------------------- Moreover in 5.2 : " For path computation, [I-D.busibel-teas-yang-path-com= putation] presents now only use cases but YANG model work is also under consideration to provide statelss path computation RPC. There is currently ongoing discussions on how to provide such a function using the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a base." There is no explicit mention of the compute_only solution , since , as you = know, also RPC solution will be supported together with compute_only. We did not provide specific details. Thanks Sergio (as co-author) From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:15 PM To: Daniele Ceccarelli ; CCAMP (ccamp@ietf= .org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 Hi, In the 4.4. Function Summary and Related YANG Models, I rea= d: +-------------+-----------------------+-----------------------+ |Path Comp. | Path Computation pre | | | | service provisioning | NONE | +-------------+-----------------------+-----------------------+ I disagree with this assessment. TE tunnel model defines the COMPUTE_ONLY m= ode explicitly designed to be used to support Path computation NBI. Cheers, Igor From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Thursday, November 03, 2016 5:13 AM To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97 Hi all, the first version of the agenda for the CCAMP session and the Joint YANG se= ssion is available at the following link. https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01 Please let us have your comments Thanks MPLS, PCE, TEAS and CCAMP (chairs and secretaries) --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Igor, you probably have an older version:=

 

+-------------+-----------------------+-= --------------------------+
         |Path Comp.   | = Path Computation pre  |        = ;            &n= bsp;      |
         |    &= nbsp;        | service provisioning = ; |     ietf-te.yang      = ;    |
         +-------------+---= --------------------+-------------------------

 

Moreover in 5.2 : “   For path compu= tation, [I-D.busibel-teas-yang-path-computation]
   presents now only use cases but YANG model work is also under<= br>    consideration to provide statelss path computation RPC.  = There is
   currently ongoing discussions on how to provide such a functio= n using
   the TE tunnel model defined in [I-D.ietf-teas-yang-te] as a ba= se.”

 

There is no explicit mention of the compute_only sol= ution , since , as you know, also RPC solution will be supported together w= ith compute_only.

We did not provide specific details.

 

Thanks

Sergio (as co-author)

 

 

 

From: Teas [mailto:teas-bounces@ietf.org] = On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:15 PM
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAM= P (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf= .org) <teas@ietf.org>; mpls@ietf.org
Subject: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01

 

Hi,<= /p>

 

In the 4.4.  Function Su= mmary and Related YANG Models, I read:

 

+-------------+-----------------------&= #43;-----------------------+

        = ; |Path Comp.   | Path Computation pre  |   &= nbsp;           &nbs= p;       |

        = ; |             = ;| service provisioning  |      NONE &nb= sp;           |

        = ; +-------------+-----------------------+----------------------= -+

 

I disagree with thi= s assessment. TE tunnel model defines the COMPUTE_ONLY mode explicitly desi= gned to be used  to support Path computation NBI.

 

Cheers,<= /span>

Igor

 

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

 

Hi all,

 

the first version of the agenda for the CCAMP sessio= n and the Joint YANG session is available at the following link.=

 

https://www.ietf.org/proceedings/97/agenda/agenda-97-= ccamp-01

 

Please let us have your comments

 

Thanks

MPLS, PCE, TEAS and CCAMP (chairs and secretaries)

--_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ACBCFR711WXCHMBA05z_-- From nobody Thu Nov 3 06:45:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7221299E1; Thu, 3 Nov 2016 06:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqN30VaULo2H; Thu, 3 Nov 2016 06:45:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21573129522; Thu, 3 Nov 2016 06:45:14 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6846FB83E63C8; Thu, 3 Nov 2016 13:45:10 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3DjC8r003520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 13:45:13 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3Dj8wu005751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 14:45:12 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 14:44:54 +0100 From: "Scharf, Michael (Nokia - DE)" To: Igor Bryskin , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw Date: Thu, 3 Nov 2016 13:44:54 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:45:18 -0000 --_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas= @ietf.org); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS W= G (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Hi,

&n= bsp;

From th= e draft:

&n= bsp;

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

&n= bsp;

--_000_655C07320163294895BBADA28372AF5D48B5BB53FR712WXCHMBA15z_-- From nobody Thu Nov 3 06:49:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44451299E9; Thu, 3 Nov 2016 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txepo0hc_7Kz; Thu, 3 Nov 2016 06:49:43 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FDD129A00; Thu, 3 Nov 2016 06:49:31 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-a4-581b4069d8d2 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B8.32.03250.9604B185; Thu, 3 Nov 2016 14:49:29 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 14:49:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K8HlXFRnjb3hWR83Kvj6REsqhN01G9WBPsfdgm09jzo=; b=gqO8Ms+YIJ2clnPd0TARZnlmMkFh6CJGCo7RmDs84Zfpi8vFXxhnfXLcQbuzxDx4leGtv9Hi7o3YKzzv8wi/TPyVPtQ7bVO58mWSDX3r+sx/ccTa6U1LDsGI2adGPigTsHOHx2jZNy9xcn6LwD1bFZBy/5B9bXCfj27To5K/yEo= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 13:49:20 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 13:49:20 +0000 From: Daniele Ceccarelli To: "Scharf, Michael (Nokia - DE)" , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9A= Date: Thu, 3 Nov 2016 13:49:20 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 49ba50ff-ba92-4488-c174-08d403f03675 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:iq2vVnk2mS69OOwuMx4uEzXGnA4F4vEaicDJrH6j00/GoVQu49LLfopcmQTbtZ/JzdoU03i4QvErBb8TkerItw5LZ2lhWI/2nzN9khnUUW9RAt88uxnlSCzGkZrrddACoL3S+EgWRMog35w1vRpuOqlvip/faMKCgj64zSWX715oQLHO4IjnT9XB0M6nGzf3pclZFgOsoxRN9ydREVBJ4QVTBxhaL28zzC/fVZnPjkjHCzhpfCIOqYa7tB78QR0CpP0IGDIbdW++iv00hmKAl7ISTr8xizpI0XIs0BIr6pbC6H1dhnhVBifwSDlCn+2fQhwU64RF2jHqnRRJS+B2ZWUtE3bk+RHsoEzbq8nMZbc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(199003)(2900100001)(122556002)(15975445007)(77096005)(50986999)(86362001)(33656002)(101416001)(19625215002)(220493001)(66066001)(16236675004)(92566002)(76176999)(106356001)(106116001)(105586002)(54356999)(586003)(3846002)(19300405004)(2906002)(6116002)(790700001)(102836003)(19617315012)(230783001)(68736007)(76576001)(19580395003)(19580405001)(8936002)(81156014)(81166006)(8676002)(74316002)(9686002)(3280700002)(2501003)(5002640100001)(7736002)(7846002)(7906003)(7696004)(189998001)(87936001)(107886002)(11100500001)(5660300001)(2950100002)(10400500002)(97736004)(3660700001)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 13:49:20.5642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03Sa0iTURgHcM57ma/S4LQ0nzY/5DATTVOTGCMvZZlUplHRiKJmvnjfZJum 0geTpkyyTA3UghS85C3zUg1U1FGEKWiWYUuxUjG1EiJviVrvjoHffs//eTiH83A4WtLNSrl4 jYHXadRJcpEDU6p6ccw7PkSm8p3t8FVMPhxhFGu9foqVt54Ka1Utq8geH7FTGJfNTIgo/NbL H2x4ZeUKFT5mHaKi6IsOh2L4pPg0Xrc/6KpDXGtOP5vSYELpLV+/oCw0nJmHOA5wAFgnTuYh B06CnyAofrrMkOI1go0+KysUDM6n4dnyOk06RRQsFn2mSPEKwXxVLS2cJcJKmLScEnJHfJOC np+/7PKQPbcDn4eutnpGsCM+B0vG53bESliz9ogEM9gNBmqzbRbjS/C7pIklF8wieFdeQQkN e3wZPg1u0IIR3glLbxpsOY2dwTr5yGbAGCo7BmhiJ5iZWGfJfDQ0Gc2bM64wWFdGkQVEQPNA unAX4HIaOkxZLJkJg/l7VkScCLmmic08ARZK/oiIzQgqCj2IXeBx79RmXiOC4f5wwRLMQ02j EZFFSGHsvWnTLvBttJMtQB5lW55ArIWF3CFRmW0X26G3dJIhuQ+M3C8WEXtBdcUcTewNJesW ZmtejuzqkJOe10cnx/r7+/C6+Gt6vVbjo+ENLejfv+ppW/U1o5npwxaEOSTfJk7Z2KWSsOo0 fUayBQFHyx3Fo8EylUQco87I5HXaK7rUJF5vQTKOkTuLD9aOX5DgWLWBT+T5FF73v0tx9tIs dFc2mpT6UJmjHHV1z23tbYxoXprqUg8WGPZ6BLef7VT7liY3D02FRi5KLftinOpDKilx5Fw3 tGbfCbr+ISosP0g6kXCgbTAQTxealOlnPp4IvuGY+L1PEbonWeV+VHx7Snvcs9Vfdrq6sX23 mzbQNfdIVHZmwIMBjasBqrxWjXJGH6f286R1evVfuArvoVMDAAA= Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:49:46 -0000 --_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin ; Daniele Ceccarelli ; CCAMP (ccamp@ietf.org) ; pce@ietf.or= g; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Can you please explain what the “stateful compute-only” s= tands for I don’t understand what is stateful in a path computation r= equest only.

IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute = a path and then forget about it or I ask to compute and provision it. I don= ’t understand the value of asking for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com>; Daniele Ceccarelli= <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@ietf.org) <ccamp@= ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; = mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

&n= bsp;

From th= e draft:

&n= bsp;

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

&n= bsp;

--_000_AM2PR07MB0994C0B4EB099666B97844C0F0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 06:50:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E739D129A0E; Thu, 3 Nov 2016 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ4Lg9H6oppD; Thu, 3 Nov 2016 06:49:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2921299FB; Thu, 3 Nov 2016 06:49:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL33957; Thu, 03 Nov 2016 13:49:33 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 13:49:32 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 06:49:28 -0700 From: Igor Bryskin To: "Scharf, Michael (Nokia - DE)" , "Daniele Ceccarelli" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQA//+LfxA= Date: Thu, 3 Nov 2016 13:49:27 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581B406D.0245, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:49:49 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, Yang 1.1 action is a form of RPC. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Thursday, November 03, 2016 9:45 AM To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org;= TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas= @ietf.org); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

 

Yang 1.1 action is a f= orm of RPC.

 

Igor=

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ie= tf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS W= G (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF66dfweml501mbx_-- From nobody Thu Nov 3 06:58:05 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B549A129633; Thu, 3 Nov 2016 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCOQKf8GbR2r; Thu, 3 Nov 2016 06:58:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3FC1295F5; Thu, 3 Nov 2016 06:58:00 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 381DFE923939F; Thu, 3 Nov 2016 13:57:56 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3Dvwj0021959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 13:57:58 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3DvsIh022252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 14:57:56 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 14:57:41 +0100 From: "Scharf, Michael (Nokia - DE)" To: Daniele Ceccarelli , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw///xlACAABFawA== Date: Thu, 3 Nov 2016 13:57:40 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:58:03 -0000 --_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

&n= bsp;

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsso= n.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org=
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 =

BR
Daniele 

 =

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.=

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_655C07320163294895BBADA28372AF5D48B5BC01FR712WXCHMBA15z_-- From nobody Thu Nov 3 07:03:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28682129A1B; Thu, 3 Nov 2016 07:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdPSAlr1qOk9; Thu, 3 Nov 2016 07:03:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E92412962E; Thu, 3 Nov 2016 07:03:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZP87813; Thu, 03 Nov 2016 14:03:40 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 14:03:40 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 07:03:36 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgD//4thsA== Date: Thu, 3 Nov 2016 14:03:35 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.581B43BD.0115, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:03:47 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin ; Daniele Ceccarelli ; CCAMP (ccamp@ietf.org) ; pce@ietf.or= g; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

HI Daniele,=

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract link to it= s own client, in some failure restoration scheme or as a part of disaster r= ecovery network topology re-configuration). In this case the client would want to know at least  if/when the path= has stopped being feasible any longer or (ideally) a better path is availa= ble.

 

Igor=

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.or= g); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com>; Daniele Ceccarelli= <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@ietf.org) <ccamp@= ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; = mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EF96dfweml501mbx_-- From nobody Thu Nov 3 07:19:29 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B95129644; Thu, 3 Nov 2016 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pAQuu_Z0XXZ; Thu, 3 Nov 2016 07:19:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B271129406; Thu, 3 Nov 2016 07:19:17 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-94-581b47647cda Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 84.58.03250.4674B185; Thu, 3 Nov 2016 15:19:16 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 15:19:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FMwtXQkUzdn5bj7ptbTj78TAFI5mdjoyyR2X0AhJmqg=; b=TcGZqKWuXEYIYMgp7m8kXKKkfdpMnzpALtzrsoj15atlEBa/S2TSjGjsOStDtS/o+7s6v+PhD2PUlbbso44bel5GdRPTzxBznEct+HsCUL3mYaX3eY2CiIju/bL3y3kZvhA9YWi3Rw7CYOtDlCx6byE3SiQgiQiDsNJ+y32aTrE= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Thu, 3 Nov 2016 14:19:13 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 14:19:13 +0000 From: Daniele Ceccarelli To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9CAAAS6gIAAAJSQ Date: Thu, 3 Nov 2016 14:19:13 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8768911b-a5e2-409c-66dc-08d403f46318 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0994; 7:8olppoFje5h1FFI6SGb9FtQv/9PZhufmJaveFqovm5EnVnU91jwVjgMDAEwfOBF7H4rBGTVc6TvEbMgsAZoBnsr6cdInlWW4d20fh9ESpqWq+1RyLCpMziO9gA7OPbiSzWMHr0A40KcsZj/ZgNNBxHyJ1j0rxcoVYRZ7oTQ5rcDK2RGoRtkPfUxNQb/AcnNHroZnsF4ya953TSSFJdnDO+5MLzMVGYwn0nN7+lbXr7EH/SH7LUaoEJzn16GVJJ97kyjC+TqfjsGu3cc/zp401NOrJ+MFGYk0dLRjGmhntT5HgZMb/p6O8/7an1dUDG4+kDdjOOf3VeIFt43u9+i1/RkxElXmWAZNdy8AK1SA1bk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0994; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0994; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(377454003)(19580405001)(2950100002)(10400500002)(7696004)(2900100001)(220493001)(66066001)(8936002)(9686002)(19580395003)(5002640100001)(93886004)(105586002)(92566002)(106356001)(19300405004)(77096005)(15975445007)(11100500001)(19617315012)(76576001)(68736007)(106116001)(87936001)(790700001)(3846002)(102836003)(6116002)(2906002)(19625215002)(586003)(3660700001)(8676002)(3280700002)(81166006)(101416001)(5001770100001)(50986999)(16236675004)(54356999)(107886002)(97736004)(81156014)(189998001)(76176999)(7906003)(7736002)(7846002)(2501003)(5660300001)(74316002)(122556002)(230783001)(86362001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0994; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 14:19:13.3478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0994 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG/c45247DwdfSfJ1SOkpC8V4xREL/0AwUioxEIpt5vKRusqlk kGg6QSmVmHilNOwyb5VIrrTUg1ETzJVdxEtqeUnLEFTmMrW2s8D/ft/zPt/78L68NClmeRI6 VZHFqBTydClfSNXEdoX7JJ5wjfWf/rNfNls/Ssm2DAEy8zsv2dg9HU92fWpUINNs6KlQfmTR wDIvsqnJTEROjr0nTpFxwpBEJj01h1H5Hb8oTBksMJKZwyy6slnUz89Hn9pQKbKnAR8BTUut oBQJaTFuR1BvNpLc4zUCs65KYHFR+CYJ0yuhXEFLwMhnrfW7GL9C8LbudCmiaT4Ohlk2yuJx xAUErLeXUBbPXnwWejtbrOyIY8CkeSrgOAIMnQ0UF3AQhkq6rD1F+DyMl3XwuLANAn6uNVpN 9jgcjEs1PAsjvA9Mg62EhUnsDGOzdwhuHgxNPcMkx06w+G3b5k+ARxq9zeMBxuZaG0dD+eqM dX7ADSTorcmWQgT0da/ZlpQGfSXdNv0yrFf/5nOsRzD3huHYDR4a5vhcoyd8GDAtEdyKGHjQ pkHcKiQw+aHExm7wfeIFrwIdrt01BMdKKB6ZsbII7wFDzSzF6b4wWqnlc+wN9xt/kBz7QPU2 S+3WG5CgGTmpGXVCRnJgoC+jSr2kVisVvgomqwP9u6z+zk1/PVpcCGMRppHUQZS54xIr5slz 1LkZLAKalDqKqiJcY8WiRHnuVUaljFdlpzNqFrnSlNRZdEw3dU6Mk+VZTBrDZDKq/1WCtpfk o7tsW7nHR39tXoOyca1pcDpuorxPP1/w7JZdcMjOn94Zz6LNtqDCyqQNd5nnSnGMyRwVOqRj /eafS77eiA66MLHlIfFyT/jlosimiDN5MbkVX4ze1Y+Tlh3GqtxbF04G5OnGD00eXT1gjPeK XyzTTvZ0mzJeSu2uhc3UFRYk3m6RUuoUeYAXqVLL/wKoF71FVQMAAA== Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:19:27 -0000 --_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, Understood the concept. It is clear but I'm still struggling with its usefu= lness. What you call statefull and stateless is with respect to the domain = controller, but I see the statefullness and stateless of the paths an highe= r level controller issue and fair enough to have the stateless concept in t= he domain controller. In other words if the higer level controller wants to keep the state of the= path why doesn't it simply do that instead of demanding it to the domain c= ontroller? Because if should be made available also to someone else? Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:04 To: Daniele Ceccarelli ; Scharf, Michael (= Nokia - DE) ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

Understood the concept. It is clear but I’m still struggling wi= th its usefulness. What you call statefull and stateless is with respect to= the domain controller, but I see the statefullness and stateless of the paths an higher level controller issue and fair enoug= h to have the stateless concept in the domain controller.=

In other words if the higer level controller wants to keep the state = of the path why doesn’t it simply do that instead of demanding it to = the domain controller? Because if should be made available also to someone else?

 

Cheers

Daniele 

 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scha= rf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

HI Dani= ele,

&n= bsp;

A clien= t may ask for a path not to be used immediately (e.g. to present as an abst= ract link to its own client, in some failure restoration scheme or as a par= t of disaster recovery network topology re-configuration). In this case the client would want to know at least &nb= sp;if/when the path has stopped being feasible any longer or (ideally) a be= tter path is available.

&n= bsp;

Igor

&n= bsp;

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_AM2PR07MB0994F166F428A91D580356A3F0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 07:25:01 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C3129A3D; Thu, 3 Nov 2016 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xChB27rdT30z; Thu, 3 Nov 2016 07:24:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D3D129669; Thu, 3 Nov 2016 07:24:53 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 458121ECD4DA; Thu, 3 Nov 2016 14:24:48 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3EOoFb030903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 14:24:51 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3EOlTV001216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 15:24:49 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.62]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 15:24:32 +0100 From: "Belotti, Sergio (Nokia - IT)" To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcdFm7Ey8mkl0SoOXT6dUSe8qDHNHgAgAABRYCAABkugA== Date: Thu, 3 Nov 2016 14:24:32 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:24:56 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Igor, this is correct. But if I remember well last weekly tunnel model discussion, action proposal= to support stateless solution is still in alternative to a normal RPC. I guess in the new module Tarek has already created "arrangement" for both. Thanks Sergio From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE) ; Daniele Ceccar= elli ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Michael, Yang 1.1 action is a form of RPC. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Thursday, November 03, 2016 9:45 AM To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Igor, this is correct.

But if I remember well last weekly tunnel model disc= ussion, action proposal to support stateless solution is still in alternati= ve to a normal RPC.

I guess in the new module Tarek has already created = “arrangement” for both.

 

Thanks

Sergio

 

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; D= aniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Michael,

 

Yang 1.1 action is a f= orm of RPC.

 

Igor=

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_B9FEE68CE3A78C41A2B3C67549A96F48B775ADDBFR711WXCHMBA05z_-- From nobody Thu Nov 3 07:29:34 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD39F129660; Thu, 3 Nov 2016 07:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6QeP5nToXK8; Thu, 3 Nov 2016 07:29:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076B112950B; Thu, 3 Nov 2016 07:29:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL40185; Thu, 03 Nov 2016 14:29:11 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 14:29:11 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 07:29:07 -0700 From: Igor Bryskin To: "Belotti, Sergio (Nokia - IT)" , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQA//+LfxCAAH+UAP//izag Date: Thu, 3 Nov 2016 14:29:06 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EFD1@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF66@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.581B49B8.0202, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:29:20 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO we do not need both global and action RPC. The latter is more elegant = but essentially the same as the former. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Belotti, Sergio (Nok= ia - IT) Sent: Thursday, November 03, 2016 10:25 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Igor, this is correct. But if I remember well last weekly tunnel model discussion, action proposal= to support stateless solution is still in alternative to a normal RPC. I guess in the new module Tarek has already created "arrangement" for both. Thanks Sergio From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE) ; Daniele Ceccar= elli ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Michael, Yang 1.1 action is a form of RPC. Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Thursday, November 03, 2016 9:45 AM To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMHO we do not need bo= th global and action RPC. The latter is more elegant but essentially the sa= me as the former.

 

Igor=

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Belotti, Sergio (Nokia - IT)
Sent: Thursday, November 03, 2016 10:25 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Igor, this is correct.

But if I remember well last weekly tunnel model disc= ussion, action proposal to support stateless solution is still in alternati= ve to a normal RPC.

I guess in the new module Tarek has already created = “arrangement” for both.

 

Thanks

Sergio

 

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; D= aniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Michael,

 

Yang 1.1 action is a f= orm of RPC.

 

Igor=

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 9:45 AM
To: Igor Bryskin; Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:

 

6.    YANG Model for requesting Path Computation

 =

 =

  = ; Work on extending the TE Tunnel YANG model to support the need to

  = ; request path computation has recently started also in the context of=

  = ; the [TE-TUNNEL] draft.

 =

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 =

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 =

  = ; The need also for a stateless solution, based on an RPC, has been

  = ; recognized.

 =

 =

  = ; The YANG model to support stateless RPC is for further study.<= /span>

 =

 =

 =

 =

 =

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFD1dfweml501mbx_-- From nobody Thu Nov 3 07:35:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A0C129658; Thu, 3 Nov 2016 07:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7f70RW9Hlwh; Thu, 3 Nov 2016 07:35:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51FB129A3D; Thu, 3 Nov 2016 07:34:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL41023; Thu, 03 Nov 2016 14:34:52 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 14:34:52 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 07:34:46 -0700 From: Igor Bryskin To: Daniele Ceccarelli , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgD//4thsIAAfPiA//+LybA= Date: Thu, 3 Nov 2016 14:34:46 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.581B4B0D.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:35:10 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the client to keep returned by the provider path state means requesting= from the provider periodic path re-computations. Provider can re-evaluate= previously returned path in an event driven way (e.g. reacting on TED chan= ge affecting one of the path's links). From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 10:19 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Igor, Understood the concept. It is clear but I'm still struggling with its usefu= lness. What you call statefull and stateless is with respect to the domain = controller, but I see the statefullness and stateless of the paths an highe= r level controller issue and fair enough to have the stateless concept in t= he domain controller. In other words if the higer level controller wants to keep the state of the= path why doesn't it simply do that instead of demanding it to the domain c= ontroller? Because if should be made available also to someone else? Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:04 To: Daniele Ceccarelli ; Scharf, Michael (= Nokia - DE) ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For the client to keep= returned by the provider path state means requesting from the provider per= iodic path re-computations.  Provider can re-evaluate previously retur= ned path in an event driven way (e.g. reacting on TED change affecting one of the path’s links).  <= /span>

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.or= g); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Hi Igor,

 

Understood the concept. It is clear but I’m st= ill struggling with its usefulness. What you call statefull and stateless i= s with respect to the domain controller, but I see the statefullness and st= ateless of the paths an higher level controller issue and fair enough to have the stateless concept in the domain controll= er.

In other words if the higer level controller wants t= o keep the state of the path why doesn’t it simply do that instead of= demanding it to the domain controller? Because if should be made available= also to someone else?

 

Cheers

Daniele 

 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawe= i.com]
Sent: gioved=EC 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scha= rf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

HI Daniele,=

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract link to it= s own client, in some failure restoration scheme or as a part of disaster r= ecovery network topology re-configuration). In this case the client would want to know at least  if/when the path= has stopped being feasible any longer or (ideally) a better path is availa= ble.

 

Igor=

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0EFE3dfweml501mbx_-- From nobody Thu Nov 3 07:42:46 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06E4129A89; Thu, 3 Nov 2016 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL_6GB8O3-7v; Thu, 3 Nov 2016 07:42:38 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F622129A84; Thu, 3 Nov 2016 07:42:37 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-ff-581b4cdbdb54 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 58.84.07742.BDC4B185; Thu, 3 Nov 2016 15:42:35 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 15:42:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VRZSp5GZpAGlhWkPlfIyWJVFz7eXdQd+hquGcFyBdN0=; b=IKtisCKrnqIOJXJky2tQEQbonFPgwLFsUVvAzrl8YZ6dflCky/PQ6A7uGiZ4IZupW79sV0M5Xgs8UWz65K0oc+8fc1UXZuen8USi31GTAqgi3v8mw3wiNNvhmUaCfju0JJDBQvuVKzXjfT05qf/ROSETwMm8p83vuvHSWI221OE= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 14:42:10 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 14:42:10 +0000 From: Daniele Ceccarelli To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9CAAAS6gIAAAJSQgAAIIgCAAAEokA== Date: Thu, 3 Nov 2016 14:42:10 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8910efd2-2137-4d4d-f264-08d403f797c6 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:cgw389NkduClgLnHL6he6Ws/IMSms3s5ihbyULK8+endz0SLN0bXgRJYsB4QFQbRwYbZHJcT7ebrd1KSkp118+LgRsouHZi1Bl85IfFtZwIInDG1Ep0ILaUlou4tFK6vXUCSdFITNszzVPnmeC0QUUNi4bnyxttWo5jg3zvHgbCggTxZ+GItcVAEt1ruHYjrssaY5Kkl7ME6DZVZHcsF3QsXVU+H4vek5LeXVEmJjJUVJv/oxBloOr/FGrsCQa2x0XkAht0fzgMZrTFvivvJRhhykra3E0J3jnoncGUcylERqXQLqgu20A36fk6UAFtczs1PIFHpURKyTImmpHsHadVS07Qd1VhYyGE2lCYhWL4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(199003)(2900100001)(122556002)(15975445007)(77096005)(50986999)(86362001)(33656002)(19625215002)(220493001)(101416001)(66066001)(16236675004)(92566002)(76176999)(586003)(106356001)(106116001)(54356999)(3846002)(19300405004)(2906002)(105586002)(790700001)(102836003)(6116002)(19617315012)(93886004)(230783001)(68736007)(76576001)(19580395003)(19580405001)(81156014)(81166006)(8676002)(8936002)(9686002)(3280700002)(2501003)(5002640100001)(74316002)(7736002)(7906003)(7846002)(7696004)(189998001)(87936001)(107886002)(11100500001)(5660300001)(2950100002)(10400500002)(97736004)(3660700001)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 14:42:10.3054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+845Ox5Hg6+l+Xr5x3VBjJlmxLoXpglpCamZBDbz4H0bm4n6 R2k5TSm0qaESqTGzzTISKYlUmpqXqKUuvCUazijzVmGmpuZ2Fvjf7/meh+/93oePIYWtPBcm XpbCKmXSJBHNp8oiXriLh4NcI7yLbh6QmO8NUJKVLh/JYo+nZKhax5NcHx2wk6j/NFLH6cDs tmleoFa7SASODPUSIWQk/3AMmxSfyir3HL3Ej+utNSLF+E+U1jf3i8pEc4MoH9kzgPdBd+0y mY/4jBDXIdBOaxAnOtbF3H3KIih8m4SVwWaKc4oIGFt6y+NEO4KWYQ2djxiGxgfBbAiynDvg LALm6/Ioy5CtOAxaGmqt7IBDYUH93I7jcDB8HrY+hMI7wJA1Zs0I8EVYMzUQ3IAcCop7OkmL YY/9oWOynrAwwttgofuxlUnsBEPmCoLbCIP2lZHk2BG+ja/yuHw0PFU32jLu8EFfbuNgmHmg tq4GuJKEtr/9dpwRALN3hmw1JUJFgdHGCTBfukRz3IigSuPBsRs86pqguYue0VC20GmdLMQs 1DxRI64KFxgx5dnYDb5+auIVIo/yDUuUrzdJYjn01gSXW8vYAl1lZoqLeMFASTHN8W54WPWd 5FgMpasGauN5JbLTI0cVq4pOjt3r68Uq4y+rVHKZl4xNqUfrX+t1w/LORtQ3dcKAMINEmwWK NecIIU+aqkpPNiBgSJGDoOm0a4RQECNNz2CV8ijllSRWZUCuDCVyEuzXjZ4X4lhpCpvIsgpW +d8lGHuXTBR4rSTBlDoVWjDmdu5G16ZmU60ud2E2TNHj7jlhPEImr32J7jmWrN+VIQ7puJqm i/QP/jh31k+6nNt0Urv9TP+h9tZ5Q1IsrY6qHjRnvwtf1Gx5c6FJJ5+5tdavZ3BW5GRGQE5I uKYuUfzyd/xdn/eY0Cukp/yUpPeq83Ch7w8RpYqT+niSSpX0H6voKp5WAwAA Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:42:41 -0000 --_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Makes sense. Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:35 To: Daniele Ceccarelli ; Scharf, Michael (= Nokia - DE) ; CCAMP (ccamp@ietf.org) ; pce@ietf.org; TEAS WG (teas@ietf.org) ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 For the client to keep returned by the provider path state means requesting= from the provider periodic path re-computations. Provider can re-evaluate= previously returned path in an event driven way (e.g. reacting on TED chan= ge affecting one of the path's links). From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 10:19 AM To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Igor, Understood the concept. It is clear but I'm still struggling with its usefu= lness. What you call statefull and stateless is with respect to the domain = controller, but I see the statefullness and stateless of the paths an highe= r level controller issue and fair enough to have the stateless concept in t= he domain controller. In other words if the higer level controller wants to keep the state of the= path why doesn't it simply do that instead of demanding it to the domain c= ontroller? Because if should be made available also to someone else? Cheers Daniele From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com] Sent: gioved=EC 3 novembre 2016 15:04 To: Daniele Ceccarelli >; Scharf, Michael (Nokia - DE) >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG (teas@ietf.org) >; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 HI Daniele, A client may ask for a path not to be used immediately (e.g. to present as = an abstract link to its own client, in some failure restoration scheme or a= s a part of disaster recovery network topology re-configuration). In this c= ase the client would want to know at least if/when the path has stopped be= ing feasible any longer or (ideally) a better path is available. Igor From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 9:49 AM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Makes sense.

 

Cheers

Daniele 

 

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: gioved=EC 3 novembre 2016 15:35
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scha= rf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@iet= f.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <te= as@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

For the= client to keep returned by the provider path state means requesting from t= he provider periodic path re-computations.  Provider can re-evaluate p= reviously returned path in an event driven way (e.g. reacting on TED change affecting one of the path’s links).=  

 <= /span>

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Igor,

 

Understood the concept. It is c= lear but I’m still struggling with its usefulness. What you call stat= efull and stateless is with respect to the domain controller, but I see the= statefullness and stateless of the paths an higher level controller issue and fair enough to have the stateless con= cept in the domain controller.

In other words if the higer lev= el controller wants to keep the state of the path why doesn’t it simp= ly do that instead of demanding it to the domain controller? Because if sho= uld be made available also to someone else?

 

Cheers

Daniele 

 

 

From: Igor Bryskin [mailto= :Igor.Bryskin@huawei.com]
Sent: gioved=EC 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scharf, Michael (Nokia -= DE) <michael.scharf@nokia.c= om>; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

HI Dani= ele,

 <= /span>

A clien= t may ask for a path not to be used immediately (e.g. to present as an abst= ract link to its own client, in some failure restoration scheme or as a par= t of disaster recovery network topology re-configuration). In this case the client would want to know at least &nb= sp;if/when the path has stopped being feasible any longer or (ideally) a be= tter path is available.

 <= /span>

Igor

 <= /span>

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00
<= /span>

 =

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"EN-US">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"EN-US">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_-- From nobody Thu Nov 3 11:49:38 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E79129570; Thu, 3 Nov 2016 11:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGHk6Nc3ezoa; Thu, 3 Nov 2016 11:49:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208701293EB; Thu, 3 Nov 2016 11:49:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL71260; Thu, 03 Nov 2016 18:49:18 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 18:49:18 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 11:49:08 -0700 From: Leeyoung To: "Scharf, Michael (Nokia - DE)" , "Daniele Ceccarelli" , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaA Date: Thu, 3 Nov 2016 18:49:07 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.581B86AF.00D9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:49:28 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org;= TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ie= tf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2dfweml501mbx_-- From nobody Thu Nov 3 12:17:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3A11296A5; Thu, 3 Nov 2016 12:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5eoBhYaRY2F; Thu, 3 Nov 2016 12:16:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DD1129617; Thu, 3 Nov 2016 12:16:40 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EF8C6B420E913; Thu, 3 Nov 2016 19:16:34 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3JGbLl015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 19:16:38 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3JGbg0007164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 20:16:37 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 20:16:37 +0100 From: "Scharf, Michael (Nokia - DE)" To: Leeyoung , Daniele Ceccarelli , Igor Bryskin , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw///xlACAABFawIAAQmiAgAAWg9A= Date: Thu, 3 Nov 2016 19:16:36 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:16:46 -0000 --_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IsnR= 17;t the intention of defining „compute-only tunnels“ to create= state in the controller, but not to signal them? If the tunnel should be s= ignaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can= be encoded in YANG. Is there anything I miss here?

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Hi Mich= ael,

&n= bsp;

I think= I am with you on your point. If we use rpc, it is clear. On the other hand= , if we were to use “stateful compute-only” it seems that the s= ystem/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datas= tore is updated only when the path is signaled and resource is allocated. W= ould this give the system/controller additional burden to keep the “i= nterim” state?

&n= bsp;

Young

&n= bsp;

From: CCAMP [mail= to:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

&n= bsp;

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

&n= bsp;

Michael=

&n= bsp;

&n= bsp;

&n= bsp;

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 =

BR
Daniele 

 =

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.=

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 <= /span>

From th= e draft:

 <= /span>

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_-- From nobody Thu Nov 3 12:34:01 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36E3129675; Thu, 3 Nov 2016 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH_jzhkaif0q; Thu, 3 Nov 2016 12:33:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AF51296C2; Thu, 3 Nov 2016 12:33:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL74804; Thu, 03 Nov 2016 19:33:47 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 19:33:46 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 12:33:39 -0700 From: Igor Bryskin To: "Scharf, Michael (Nokia - DE)" , Leeyoung , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoA== Date: Thu, 3 Nov 2016 19:33:38 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.581B911B.030E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:33:56 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce= @ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.or= g); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F10Bdfweml501mbx_-- From nobody Thu Nov 3 12:42:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55A1296B7; Thu, 3 Nov 2016 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZC02QuPPWLB; Thu, 3 Nov 2016 12:42:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27A51296F6; Thu, 3 Nov 2016 12:42:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUL75453; Thu, 03 Nov 2016 19:41:58 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 19:41:58 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 12:41:48 -0700 From: Leeyoung To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAB+lgCAAATCAP//jJXQ Date: Thu, 3 Nov 2016 19:41:47 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.581B9307.016A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 757543bd283f5f15f63d24868614daf9 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:42:04 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA51dfweml501mbx_-- From nobody Thu Nov 3 13:02:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4857129431; Thu, 3 Nov 2016 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb47fUC09Y6j; Thu, 3 Nov 2016 13:02:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223801296F6; Thu, 3 Nov 2016 13:02:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZQ31552; Thu, 03 Nov 2016 20:02:33 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 20:02:32 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 13:02:21 -0700 From: Igor Bryskin To: Leeyoung , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kA= Date: Thu, 3 Nov 2016 20:02:20 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.581B97D9.02E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:02:41 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F12Ddfweml501mbx_-- From nobody Thu Nov 3 13:12:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835B129762; Thu, 3 Nov 2016 13:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgB0rUaAecaB; Thu, 3 Nov 2016 13:12:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D7912973D; Thu, 3 Nov 2016 13:12:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZQ32363; Thu, 03 Nov 2016 20:12:25 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 20:12:24 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 13:12:14 -0700 From: Leeyoung To: Igor Bryskin , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAB+lgCAAATCAP//jJXQgAB7cAD//4r10A== Date: Thu, 3 Nov 2016 20:12:14 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.581B9A2A.00FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:12:38 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCA9Bdfweml501mbx_-- From nobody Thu Nov 3 15:27:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7741129453; Thu, 3 Nov 2016 15:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYNAR96yepYT; Thu, 3 Nov 2016 15:27:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A331E129975; Thu, 3 Nov 2016 15:27:32 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id F0FB410E0B51C; Thu, 3 Nov 2016 22:27:25 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3MRTVg010253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 22:27:30 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3MRTuK011396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 23:27:29 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.36]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 23:27:28 +0100 From: "Beller, Dieter (Nokia - DE)" To: Young Lee Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNiF1aOOcuqLRzEGcGyhR2xJLlw== Date: Thu, 3 Nov 2016 22:27:28 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: Igor Bryskin , "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:27:36 -0000 --_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say =93state=94, are you referring to the YANG datastore or some o= ther =93interim=94 state of those paths that are calculated but not instant= iated as LSPs? If we were to update the YANG datastore for this, I would th= ink that we may have some issue when the customer decided not to instantiat= e the TE tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as =93normal=94 (COMPUTE_ADN_PROVISION) TE tunnels= . Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the =93compute-only=94 TE tunnel is t= o create/maintain the normal TE tunnel state and (re-)compute TE paths for = the TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn=92t the intention of defining =84compute-only tunnels=93 to create stat= e in the controller, but not to signal them? If the tunnel should be signal= ed and resources shall be allocated, why not just configure a vanilla tunne= l? Uses cases seem to exist for both variants, and both can be encoded in Y= ANG. Is there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use =93stateful compute-only=94 it seems that the sy= stem/controller has to keep the state of the paths somewhere which is not Y= ANG datastore. My understanding is that YANG datastore is updated only when= the path is signaled and resource is allocated. Would this give the system= /controller additional burden to keep the =93interim=94 state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the =93stateful compute-only=94 stands for I do= n=92t understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don=92t u= nderstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer=92s perspective, the two= clean solutions to the problem seem to either stateful =84compute-only=93 = tunnels or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all, =0A=
=0A=
when we talk about the stateful path computation use case, it means IMHO th=
at when a path has been calculated successfully in response to a request, a=
 new path object is created in the data store. This does only make sense if=
 the resources have been allocated in the TED of the PCE irrespective of th=
e fact whether the connection along this path will be established right awa=
y or at a later point in time. This will prevent further path computation r=
equests from assuming that the resources are still available. As the TED of=
 the PCE also has to reflect the network state, I would assume that the net=
work resources can be in one of the following three states: available, allo=
catedButNotInUse,  allocatedAndInUse. The path objects also need state info=
rmation reflecting for example the alarm state of the allocated resources. =
The path calculated earlier may become (temporarily) invalid due to a link =
failure affecting the path. =0A=
=0A=
Does this make sense? =0A=
=0A=
=0A=
Thanks, =0A=
Dieter=0A=
=0A=
Sent from my tablet=0A=
=0A=
Leeyoung <leeyoung@huawei.com> wrote:=0A=
=0A=

Igor,

 

When you say =93state= =94, are you referring to the YANG datastore or some other =93interim=94 st= ate of those paths that are calculated but not instantiated as LSPs? If we = were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor B= ryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as =93normal=94 (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor

 

From: Leeyou= ng
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor B= ryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the =93compute-only=94 TE tunnel is to create/maintain the = normal TE tunnel state and (re-)compute TE paths for the TE tunnel connecti= ons/LSPs but not signal/provision the LSPs.

 

Igor

 

From: Scharf= , Michael (Nokia - DE) [mailto:= michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn=92t the intention = of defining =84compute-only tunnels=93 to create state in the controller, b= ut not to signal them? If the tunnel should be signaled and resources shall= be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:l= eeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use =93stateful compute-only=94 it seems that the system/controller has to= keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the =93interim=94 state?

 

Young

 

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniel= e Ceccarelli [mailto:dan= iele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Ig= or Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the =93stateful compute-= only=94 stands for I don=92t understand what is stateful in a path computat= ion request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don=92t understand the value of asking for it and remembering= about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer=92s perspective, the two clean solutions to th= e problem seem to either stateful =84compute-only=93 tunnels or a stateless= RPC.

 

Michael

 

 

From: mpls [mailto:mpl= s-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6. = ;   YANG Model for requesting Path Computation

 

 

 &nbs= p; Work on extending the TE Tunnel YANG model to support the need to=

 &nbs= p; request path computation has recently started also in the context of

 &nbs= p; the [TE-TUNNEL] draft.

 

 &nbs= p; It is possible to request path computation by configuring a

 &nbs= p; "compute-only" TE tunnel and retrieving the computed path(s) i= n the

 &nbs= p; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

 &nbs= p; This is a stateful solution since the state of each created

 &nbs= p; "compute-only" TE tunnel needs to be maintained and updated, w= hen

 &nbs= p; underlying network conditions change.

 

 &nbs= p; The need also for a stateless solution, based on an RPC, has been=

 &nbs= p; recognized.

 

 

 &nbs= p; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_slkuudfq6hfpvsvrdv85tj8f1478211220486emailandroidcom_-- From nobody Thu Nov 3 15:51:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8351C1296F0; Thu, 3 Nov 2016 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BJXsoOefljo; Thu, 3 Nov 2016 15:51:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC15B1296DE; Thu, 3 Nov 2016 15:51:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZQ46250; Thu, 03 Nov 2016 22:51:03 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 22:51:02 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 15:50:50 -0700 From: Leeyoung To: "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAB+lgCAAATCAP//jJXQgAB7cAD//4r10AATswsAAA5+WSA= Date: Thu, 3 Nov 2016 22:50:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.249] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581BBF58.0286, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bee9e4788904c3a2f3d547c3eaf515ee Archived-At: Cc: Igor Bryskin , "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:51:11 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dieter, Thanks for your clear explanation on this issue. I have no problem with tha= t. However, my real concern of the Tunnel mode with "compute only" is the a= ssumption people are making. That is, The tunnel mode with "compute only" w= ill make sense to me only when the requests turn into instantiation of tunn= els (the paths are signaled and resource allocated in the network) immediat= ely following the request. But what assures that this always happens? If th= e path computation request would not turn into instantiation right away the= n the "resource allocated but not in use" would turn out to be wasteful. I still think the stateless RPC mechanism for path compute would make sense= s to the situations where the aforementioned assumption does not hold. What= do you think? Thanks. Young From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 5:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung > wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dieter,<= /span>

 

Thanks for your clear = explanation on this issue. I have no problem with that. However, my real co= ncern of the Tunnel mode with “compute only” is the assumption = people are making. That is, The tunnel mode with “compute only” will make sense to me only when the requests tu= rn into instantiation of tunnels (the paths are signaled and resource alloc= ated in the network) immediately following the request. But what assures th= at this always happens? If the path computation request would not turn into instantiation right away then the “resou= rce allocated but not in use” would turn out to be wasteful.

 

I still think the stat= eless RPC mechanism for path compute would make senses to the situations wh= ere the aforementioned assumption does not hold. What do you think?  <= o:p>

 

Thanks.

Young

 

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computati=
on use case, it means IMHO that when a path has been calculated successfull=
y in response to a request, a new path object is created in the data store.=
 This does only make sense if the resources have been allocated in the TED =
of the PCE irrespective of the fact whether the connection along this path =
will be established right away or at a later point in time. This will preve=
nt further path computation requests from assuming that the resources are s=
till available. As the TED of the PCE also has to reflect the network state=
, I would assume that the network resources can be in one of the following =
three states: available, allocatedButNotInUse,  allocatedAndInUse. The=
 path objects also need state information reflecting for example the alarm =
state of the allocated resources. The path calculated earlier may become (t=
emporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9dfweml501mbx_-- From nobody Thu Nov 3 18:15:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BB12949C; Thu, 3 Nov 2016 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jatPbAw4Gp7; Thu, 3 Nov 2016 18:15:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA221129408; Thu, 3 Nov 2016 18:15:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM00547; Fri, 04 Nov 2016 01:15:46 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 01:15:44 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.52]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 09:15:36 +0800 From: "Zhangxian (Xian)" To: Igor Bryskin , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 Thread-Index: AQHSNdRhXq9GHGb5y06beM5s18Fn46DIBX2g Date: Fri, 4 Nov 2016 01:15:35 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EF03@dfweml501-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.139.68] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.581BE142.01E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9c988c89008e6ba1609782767c4130b8 Archived-At: Subject: Re: [mpls] [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:15:52 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIElnb3IsDQoNCiAgICAgIFRoYW5rIHlvdS4gQnV0IHlvdSBhcmUgZGlzYWdyZWVpbmcgd2l0 aCBhIG9sZCB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQuIEF0IHRoYXQgdGltZSwgaXQgd2FzIGluZGVl ZCBubyBJRVRGIG1vZGVsIHByb3ZpZGluZyB0aGlzIGZ1bmN0aW9uYWxpdHksIDopLg0KDQpUaGUg bGF0ZXN0IHZlcnNpb24gKDAxKSB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgc3RhdGVzOg0KDQogICAg ICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQogICAgICAgICB8UGF0aCBDb21wLiAgIHwgUGF0aCBDb21wdXRhdGlv biBwcmUgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICB8ICAgICAgICAg ICAgIHwgc2VydmljZSBwcm92aXNpb25pbmcgIHwgICAgIGlldGYtdGUueWFuZyAgICAgICAgICB8 DQogICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgIEhvd2V2ZXIsICBUaGUgZHJhZnQgYWxzbyBub3Rl cyBvbmdvaW5nIG9ubGluZS9vZmZsaW5lIGRpc2N1c3Npb25zIGFzIGJlbG93Og0KobANCiAgRm9y IHBhdGggY29tcHV0YXRpb24sIFtJLUQuYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlv bl0NCiAgIHByZXNlbnRzIG5vdyBvbmx5IHVzZSBjYXNlcyBidXQgWUFORyBtb2RlbCB3b3JrIGlz IGFsc28gdW5kZXINCiAgIGNvbnNpZGVyYXRpb24gdG8gcHJvdmlkZSBzdGF0ZWxzcyBwYXRoIGNv bXB1dGF0aW9uIFJQQy4gIFRoZXJlIGlzDQogICBjdXJyZW50bHkgb25nb2luZyBkaXNjdXNzaW9u cyBvbiBob3cgdG8gcHJvdmlkZSBzdWNoIGEgZnVuY3Rpb24gdXNpbmcNCiAgIHRoZSBURSB0dW5u ZWwgbW9kZWwgZGVmaW5lZCBpbiBbSS1ELmlldGYtdGVhcy15YW5nLXRlXSBhcyBhIGJhc2UuDQqh sA0KDQpDaGVlcnMsDQpYaWFuDQoNCreivP7IyzogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBJZ29yIEJyeXNraW4NCreiy83KsbzkOiAyMDE2xOoxMdTCM8jVIDIxOjE1 DQrK1bz+yMs6IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKTsgcGNl QGlldGYub3JnOyBURUFTIFdHICh0ZWFzQGlldGYub3JnKTsgbXBsc0BpZXRmLm9yZw0K1vfM4jog W1RlYXNdIGRyYWZ0LXpoYW5nLWNjYW1wLXRyYW5zcG9ydC15YW5nLWdhcC1hbmFseXNpcy0wMQ0K DQpIaSwNCg0KSW4gdGhlIDQuNDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctY2NhbXAtdHJhbnNwb3J0LXlhbmctZ2FwLWFuYWx5c2lzLTAwI3NlY3Rpb24tNC40Pi4gIEZ1 bmN0aW9uIFN1bW1hcnkgYW5kIFJlbGF0ZWQgWUFORyBNb2RlbHMsIEkgcmVhZDoNCg0KKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICAgICAgICB8UGF0aCBDb21wLiAgIHwgUGF0aCBDb21wdXRhdGlvbiBwcmUgIHwgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgIHwgICAgICAgICAgICAgfCBzZXJ2aWNlIHByb3Zp c2lvbmluZyAgfCAgICAgIE5PTkUgICAgICAgICAgICAgfA0KICAgICAgICAgKy0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCkkg ZGlzYWdyZWUgd2l0aCB0aGlzIGFzc2Vzc21lbnQuIFRFIHR1bm5lbCBtb2RlbCBkZWZpbmVzIHRo ZSBDT01QVVRFX09OTFkgbW9kZSBleHBsaWNpdGx5IGRlc2lnbmVkIHRvIGJlIHVzZWQgIHRvIHN1 cHBvcnQgUGF0aCBjb21wdXRhdGlvbiBOQkkuDQoNCkNoZWVycywNCklnb3INCg0KDQpGcm9tOiBQ Y2UgW21haWx0bzpwY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbGUgQ2Vj Y2FyZWxsaQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDU6MTMgQU0NClRvOiBD Q0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPik7IHBjZUBpZXRmLm9y ZzxtYWlsdG86cGNlQGlldGYub3JnPjsgVEVBUyBXRyAodGVhc0BpZXRmLm9yZzxtYWlsdG86dGVh c0BpZXRmLm9yZz4pOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVj dDogW1BjZV0gQ0NBTVAgYW5kIEpPSU5UIFlBTkcgc2Vzc2lvbiBhZ2VuZGEgQElFVEY5Nw0KDQpI aSBhbGwsDQoNCnRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBhZ2VuZGEgZm9yIHRoZSBDQ0FNUCBz ZXNzaW9uIGFuZCB0aGUgSm9pbnQgWUFORyBzZXNzaW9uIGlzIGF2YWlsYWJsZSBhdCB0aGUgZm9s bG93aW5nIGxpbmsuDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L2FnZW5k YS9hZ2VuZGEtOTctY2NhbXAtMDENCg0KUGxlYXNlIGxldCB1cyBoYXZlIHlvdXIgY29tbWVudHMN Cg0KVGhhbmtzDQpNUExTLCBQQ0UsIFRFQVMgYW5kIENDQU1QIChjaGFpcnMgYW5kIHNlY3JldGFy aWVzKQ0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Igor,

 

      Thank you. But you are disagreeing= with a old version of this draft. At that time, it was indeed no IETF mode= l providing this functionality, J.

 

The latest version (01) version of t= his draft states:

 

         +-----------= --+-----------------------+---------------------------+

         |Path Comp. = ;  | Path Computation pre  |      &= nbsp;           &nbs= p;        |

         |  &nb= sp;          | service provisi= oning  |     ietf-te.yang    &= nbsp;     |

         +-----------= --+-----------------------+---------------------------+

 

   However,  The draft also notes ongoing online/o= ffline discussions as below:

=A1=B0

  For path computation, [I-D.busibel-teas-yang-path-computat= ion]

   presents now only use cases but YANG model work is a= lso under

   consideration to provide statelss path computation R= PC.  There is

   currently ongoing discussions on how to provide such= a function using

   the TE tunnel model defined in [I-D.ietf-teas-yang-t= e] as a base.

=A1=B0

 

Cheers,

Xian

 

=B7=A2=BC=FE=C8=CB: Teas [mailto:teas-bou= nces@ietf.org] =B4=FA=B1=ED = Igor Bryskin
=B7=A2=CB=CD= =CA=B1=BC=E4: 2016=C4=EA11=D4=C2= 3=C8=D5 21:15
=CA=D5=BC=FE=C8=CB: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (= teas@ietf.org); mpls@ietf.org
=D6=F7=CC=E2: [Teas] draft-zhang-ccamp-transport-yang-gap-analysis-01=

 

Hi,

&n= bsp;

In the = 4.4.  Function Summary and= Related YANG Models, I read:

 

+-------------+---------= --------------+-----------------------+

     &n= bsp;   |Path Comp.   | Path Computation pre  |&nbs= p;            &= nbsp;         |

     &n= bsp;   |         &nb= sp;   | service provisioning  |     = ; NONE           &nb= sp; |

     &n= bsp;   +-------------+-----------------------+-------= ----------------+

 

I di= sagree with this assessment. TE tunnel model defines the COMPUTE_ONLY mode = explicitly designed to be used  to support Path computation NBI.<= /o:p>

 

Chee= rs,

Igor=

&n= bsp;

&n= bsp;

From: Pce [mailto:p= ce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Thursday, November 03, 2016 5:13 AM
To: CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [Pce] CCAMP and JOINT YANG session agenda @IETF97

 

Hi all,

 

the first version of the agenda= for the CCAMP session and the Joint YANG session is available at the follo= wing link.

 

https://www.ietf.org/proceedings= /97/agenda/agenda-97-ccamp-01

 

Please let us have your comment= s

 

Thanks

MPLS, PCE, TEAS and CCAMP (chai= rs and secretaries)

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DF4F5B1SZXEMA512MBSchi_-- From nobody Thu Nov 3 21:36:14 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D973129785; Thu, 3 Nov 2016 21:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IF3QVxWZAzh; Thu, 3 Nov 2016 21:36:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499C2129705; Thu, 3 Nov 2016 21:36:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM18041; Fri, 04 Nov 2016 04:36:04 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 04:36:02 +0000 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 10:05:53 +0530 From: Dhruv Dhody To: Leeyoung , "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdcs+kr+YSyrQ0+M0PsTNtuTxqDG6QgAgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAAGhwCAALoV8A== Date: Fri, 4 Nov 2016 04:35:52 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C9C3331@blreml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.581C1035.00B6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: Igor Bryskin , "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 04:36:12 -0000 --_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, As an implementer who would like to implement a simple path computation req= uest, the rpc is the way to go. Doing this via tunnel creation would require 3 operations. (1) POST to crea= te tunnel with "compute-only"; (2) GET to get the path; (3) DELETE tunnel. Which is an overkill to say the least. We can further debate the usefulness of Stateful compute-only mode separate= ly. Regards, Dhruv From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung Sent: 04 November 2016 04:21 To: Beller, Dieter (Nokia - DE) Cc: Igor Bryskin ; mpls@ietf.org; CCAMP (ccamp@iet= f.org) ; Scharf, Michael (Nokia - DE) ; TEAS WG (teas@ietf.org) ; pce@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Dieter, Thanks for your clear explanation on this issue. I have no problem with tha= t. However, my real concern of the Tunnel mode with "compute only" is the a= ssumption people are making. That is, The tunnel mode with "compute only" w= ill make sense to me only when the requests turn into instantiation of tunn= els (the paths are signaled and resource allocated in the network) immediat= ely following the request. But what assures that this always happens? If th= e path computation request would not turn into instantiation right away the= n the "resource allocated but not in use" would turn out to be wasteful. I still think the stateless RPC mechanism for path compute would make sense= s to the situations where the aforementioned assumption does not hold. What= do you think? Thanks. Young From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 5:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung > wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

As an implementer who would like to implement a simple= path computation request, the rpc is the way to go.

Doing this via tunnel creation would require 3 operati= ons. (1) POST to create tunnel with “compute-only”; (2) GET to = get the path; (3) DELETE tunnel.

Which is an overkill to say the least.

 

We can further debate the usefulness of Stateful compu= te-only mode separately.

 

Regards,

Dhruv

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 04 November 2016 04:21
To: Beller, Dieter (Nokia - DE) <dieter.beller@nokia.com>
Cc: Igor Bryskin <Igor.Bryskin@huawei.com>; mpls@ietf.org; CCA= MP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) &l= t;michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org&g= t;; pce@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Diet= er,

&n= bsp;

Thanks = for your clear explanation on this issue. I have no problem with that. Howe= ver, my real concern of the Tunnel mode with “compute only” is = the assumption people are making. That is, The tunnel mode with “compute only” will make sense to me only when the r= equests turn into instantiation of tunnels (the paths are signaled and reso= urce allocated in the network) immediately following the request. But what = assures that this always happens? If the path computation request would not turn into instantiation right away then the = “resource allocated but not in use” would turn out to be wastef= ul.

&n= bsp;

I still= think the stateless RPC mechanism for path compute would make senses to th= e situations where the aforementioned assumption does not hold. What do you= think?  

&n= bsp;

Thanks.=

Young

&n= bsp;

&n= bsp;

&n= bsp;

From: Be= ller, Dieter (Nokia - DE) [mailt= o:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi all, 
 
when we talk about the stateful path comput=
ation use case, it means IMHO that when a path has been calculated successf=
ully in response to a request, a new path object is created in the data sto=
re. This does only make sense if the resources have been allocated in the T=
ED of the PCE irrespective of the fact whether the connection along this pa=
th will be established right away or at a later point in time. This will pr=
event further path computation requests from assuming that the resources ar=
e still available. As the TED of the PCE also has to reflect the network st=
ate, I would assume that the network resources can be in one of the followi=
ng three states: available, allocatedButNotInUse,  allocatedAndInUse. =
The path objects also need state information reflecting for example the ala=
rm state of the allocated resources. The path calculated earlier may become=
 (temporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 <= /span>

When yo= u say “state”, are you referring to the YANG datastore or some = other “interim” state of those paths that are calculated but no= t instantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer deci= ded not to instantiate the TE tunnel (after the path compute request).

 <= /span>

Thanks.=

Young

 <= /span>

 <= /span>

From: Ig= or Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,<= /span>

 <= /span>

From th= e provider controller point of view COMPUTE_ONLY TE tunnels will have exact= ly the same state as “normal” (COMPUTE_ADN_PROVISION) TE tunnel= s.

 <= /span>

Igor

 <= /span>

From: Le= eyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 <= /span>

In such= case, would the YANG datastore be updated? I guess not. If not, then the s= ystem/controller has to keep this interim state, would it?

 <= /span>

Thanks.=

Young

 <= /span>

From: Ig= or Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael= ,

You are= exactly right. The purpose of the “compute-only” TE tunnel is = to create/maintain the normal TE tunnel state and (re-)compute TE paths for= the TE tunnel connections/LSPs but not signal/provision the LSPs.

 <= /span>

Igor

 <= /span>

From: Sc= harf, Michael (Nokia - DE) [mai= lto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

IsnR= 17;t the intention of defining „compute-only tunnels“ to create= state in the controller, but not to signal them? If the tunnel should be s= ignaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can= be encoded in YANG. Is there anything I miss here?

 <= /span>

Michael=

 <= /span>

 <= /span>

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 =

Hi Mich= ael,

 <= /span>

I think= I am with you on your point. If we use rpc, it is clear. On the other hand= , if we were to use “stateful compute-only” it seems that the s= ystem/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datas= tore is updated only when the path is signaled and resource is allocated. W= ould this give the system/controller additional burden to keep the “i= nterim” state?

 <= /span>

Young

 <= /span>

From: CC= AMP [mailto:ccamp-bounces@ietf.or= g] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I= miss something, but to me, the domain controller either computes a path st= ateless, which can be modeled in YANG in an RPC. Or the domain controller c= omputes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether re= sources are allocated, or whether the NEs get actually provisioned, is an o= rthogonal question.

 <= /span>

As a si= de note, I am not sure of I would call a domain controller or an NMS a PCE.= Path computation is only a subset of the functions of a domain controller.=

 <= /span>

Michael=

 <= /span>

 <= /span>

 <= /span>

From: Da= niele Ceccarelli [mailto= :daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igor Bryskin; C= CAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 =

Can you please explain what the= “stateful compute-only” stands for I don’t understand wh= at is stateful in a path computation request only.

IMHO either I ask the PCE (SDN = controller, NMS, whatever) to compute a path and then forget about it or I = ask to compute and provision it. I don’t understand the value of aski= ng for it and remembering about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 =

We have= discussed this before. From an implementer’s perspective, the two cl= ean solutions to the problem seem to either stateful „compute-only= 220; tunnels or a stateless RPC.

 <= /span>

Michael=

 <= /span>

 <= /span>

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00
<= /span>

 =

Hi,

 <= /span>

From th= e draft:

 <= /span>

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"EN-US">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"EN-US">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 <= /span>

--_000_23CE718903A838468A8B325B80962F9B8C9C3331blreml501mbx_-- From nobody Fri Nov 4 03:18:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971A1129B15; Fri, 4 Nov 2016 03:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUZxObjca8AJ; Fri, 4 Nov 2016 03:17:50 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37914129B2E; Fri, 4 Nov 2016 03:08:17 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-12-581c5e0f91c1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id DC.E9.07742.F0E5C185; Fri, 4 Nov 2016 11:08:15 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 4 Nov 2016 11:07:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nKDxn8YyPk37oCoymAT5iPI/wnwiyEDtZ5GZjYrKetI=; b=c/29SyhidguG59hIvp0dyrdIHyW4kisoePkPVazUGHXXOzsbbPZ4Ozm2BBXltYSMyGz/Yz0J1+EIEesUJuc2kGd3Kp5Dg9hjAFkI9EUnrJrCumCnJO1vr4YfU/+Gd4deseZhCn6ewTLHJVG5GVnjipQ7uoCvKTm0v6yfTO6PL6Q= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1523.eurprd07.prod.outlook.com (10.165.248.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Fri, 4 Nov 2016 10:07:19 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0707.004; Fri, 4 Nov 2016 10:07:19 +0000 From: Francesco Lazzeri To: Dhruv Dhody , Leeyoung , "Beller, Dieter (Nokia - DE)" Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAAJPQCAAATDAIAAAkeAgAAFvQCAAALEAIAAJckAgAAGhwCAAGBnAIAAWvUQ Date: Fri, 4 Nov 2016 10:07:19 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCBA9@dfweml501-mbx> <23CE718903A838468A8B325B80962F9B8C9C3331@blreml501-mbx> In-Reply-To: <23CE718903A838468A8B325B80962F9B8C9C3331@blreml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 8538b668-deac-4b79-2168-08d4049a5cc3 x-microsoft-exchange-diagnostics: 1; AM4PR07MB1523; 7:w438ClX9jiQ3hGaQPDC6tQReasryCZIxMNc7B1Ldt8svjLyHYt2DLUTVarB8NXhFSH7LZIYly3HO2i/s8ogrYJHCbpzYwQk/OQHnMfquXVLt2v0+FDQZJ5xv+raoonTUoI1qTsziVtN7VGXz+xP+uJcvWzzpkh1r6SbtkeQiAmpinpdewSSwGwK6K+0+BpFQxq9LDZsqcQWl2XJBl2QFFd0RY3IR9uhc542FonlY42eqNBChSHnBrycK3DJi1GEsb0epOf41k9FSC9xBRyejztSwVYIUPeGD8/sQDtLmfqz2ASH6AgBEWsfRoNWnvwHQPxMcTsbdmbim49V3zX5fpQvGBXDFL0+mDYJ4v8+6CoI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1523; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1523; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(24454002)(377454003)(76104003)(53754006)(199003)(3280700002)(11100500001)(16236675004)(19580405001)(77096005)(220493001)(81166006)(7906003)(74316002)(15975445007)(3900700001)(19580395003)(4326007)(19617315012)(189998001)(76576001)(8676002)(87936001)(33656002)(97736004)(81156014)(19609705001)(7846002)(66066001)(122556002)(3660700001)(7736002)(5001770100001)(92566002)(76176999)(2950100002)(230783001)(7696004)(54356999)(5660300001)(68736007)(86362001)(19625215002)(5002640100001)(93886004)(9686002)(8936002)(101416001)(586003)(50986999)(2906002)(6116002)(10400500002)(102836003)(2900100001)(19300405004)(3846002)(105586002)(790700001)(106116001)(106356001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1523; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 10:07:19.1997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1523 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUhUURTGuW+ZeVpT13E7qCUOFqSpbdhrwYwyBmmRaBEx65UPFXWUGZNU QtGUHAnNVMy9GjVFxdJoQtEcBHNL0yAbFKUxSVzbyIUkZ94Y/vc73/2+w/ngMqS0n3ZgIhRx vFLBRclEltTjwNdBHttDnAL3VbfvZidLRig2+3kfxTZoRim2oMyPXf7gxuora2g2dXxEzKYv aSlfRn6vc46WazTLhHxMP0QEkEGWx0P5qIh4Xunlc8MyXFvlH9vym7xTOf+QSEG/dKQaWTCA D8FP/bRYjSwZKW5AsNz6lBKGLgTvDOXIOFD4AQk1WQZSeCkgYLhtnPhv61bnIuMyEWZhpbPY lLfBaQiKppdMA4k/ISh9NEqrEcNY42B4n2FlDNjga5A/0WQOpCJI1QqbKOwKA+0rphMl6/75 hXmxkaW4TQzNE15GtsB+UJWVa9IRtoM/PXWEkUlsD/rJckKoh0HTOmCuagvThjVa8HPwQlNk 9rjAYO0Gn4PGlUzaeBDgChKaNHpz+AyUtN+njAUAR8JyPwhyInwbzxcJrEWgnjsisBNkPzNQ wp6vIjBUppkL8FBdn24qaY0dYOxjJspBe4o23S1wDDTNpNBFpv5W0P14khJ0TxjJzxMJ7A5V T2ZIgT2gcE1HbdYrkLgW2ap41c3osAMHPXllxC2VKkbhqeDjXqL1T9bRvLpLi4ZnT+oQZpBs q2QxwDFQSnPxqoRoHQKGlNlIcoOdAqWSUC4hkVfGXFfejuJVOuTIUDJ7iXfN+FUpDuPi+Eie j+WVG68EY+GQgryTwkL2Xrji4lX/d9o7T3RqLrnYdajH53Jd4sBE0t2jXna6746DjWGd8s+5 x/y3xRUunZ3IO3zRImfRNXl1R+kk7qlyjxqdm3J+9aZzLI+YzeKaO1qmeldTdp73kfe+/eGU 09wuOk2zW/qsT2QsxHTrFV+U7GBZl/wSN5PvO1PuLKNU4dx+N1Kp4v4B83nYaWADAAA= Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 10:17:54 -0000 --_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What happens in case the requested controller or PCE cannot or doesn't want= to send an explicit ERO ? In that case the path key mechanism is foreseen; the controller returns a p= ath key identifier which can be used eventually to implement the requested = path. Here something must be stored inside the controller in order to understand = the path key and translate it to the relevant route as needed. I would stor= e the path and probably would keep also reserved the relevant resources, un= til eventual operation or expiration of the path key. This cannot be avoide= d. I am wondering whether this is a completely diffent case or should be harmo= nized with the case under discussion. Regards, Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 04 November, 2016 5:36 AM To: Leeyoung ; Beller, Dieter (Nokia - DE) Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; TEAS WG (teas@ietf.org) ; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Hi All, As an implementer who would like to implement a simple path computation req= uest, the rpc is the way to go. Doing this via tunnel creation would require 3 operations. (1) POST to crea= te tunnel with "compute-only"; (2) GET to get the path; (3) DELETE tunnel. Which is an overkill to say the least. We can further debate the usefulness of Stateful compute-only mode separate= ly. Regards, Dhruv From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung Sent: 04 November 2016 04:21 To: Beller, Dieter (Nokia - DE) > Cc: Igor Bryskin >;= mpls@ietf.org; CCAMP (ccamp@ietf.org) >; Scharf, Michael (Nokia - = DE) >; TEAS WG (t= eas@ietf.org) >; = pce@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Dieter, Thanks for your clear explanation on this issue. I have no problem with tha= t. However, my real concern of the Tunnel mode with "compute only" is the a= ssumption people are making. That is, The tunnel mode with "compute only" w= ill make sense to me only when the requests turn into instantiation of tunn= els (the paths are signaled and resource allocated in the network) immediat= ely following the request. But what assures that this always happens? If th= e path computation request would not turn into instantiation right away the= n the "resource allocated but not in use" would turn out to be wasteful. I still think the stateless RPC mechanism for path compute would make sense= s to the situations where the aforementioned assumption does not hold. What= do you think? Thanks. Young From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 5:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung > wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What happens in case the requested controller or PCE= cannot or doesn’t want to send an explicit ERO ?

In that case the path key mechanism is foreseen; the= controller returns a path key identifier which can be used eventually to i= mplement the requested path.

Here something must be stored inside the controller = in order to understand the path key and translate it to the relevant route = as needed. I would store the path and probably would keep also reserved the= relevant resources, until eventual operation or expiration of the path key. This cannot be avoided.

I am wondering whether this is a completely diffent = case or should be harmonized with the case under discussion.

Regards,

Francesco

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Dhruv Dhody
Sent: 04 November, 2016 5:36 AM
To: Leeyoung <leeyoung@huawei.com>; Beller, Dieter (Nokia - DE= ) <dieter.beller@nokia.com>
Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Sc= harf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@= ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel= -teas-yang-path-computation-00

 

Hi All,

 

As an implementer who would like to implem= ent a simple path computation request, the rpc is the way to go.

Doing this via tunnel creation would requi= re 3 operations. (1) POST to create tunnel with “compute-only”;= (2) GET to get the path; (3) DELETE tunnel.

Which is an overkill to say the least.

 

We can further debate the usefulness of St= ateful compute-only mode separately.

 

Regards,

Dhruv

 

From:<= /span> mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Leeyoung
Sent: 04 November 2016 04:21
To: Beller, Dieter (Nokia - DE) <dieter.beller@nokia.com>
Cc: Igor Bryskin <Igor= .Bryskin@huawei.com>; mpls@ietf.org; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; TEAS WG (teas@ietf.org) <teas@ietf.org>; pce@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

&nbs= p;

Hi Dieter,

 

Thanks for your clear explanation on this issue. I have no problem wit= h that. However, my real concern of the Tunnel mode with “compute onl= y” is the assumption people are making. That is, The tunnel mode with “compute only” will make sense to me = only when the requests turn into instantiation of tunnels (the paths are si= gnaled and resource allocated in the network) immediately following the req= uest. But what assures that this always happens? If the path computation request would not turn into instantiation right aw= ay then the “resource allocated but not in use” would turn out = to be wasteful.

 

I still think the stateless RPC mechanism for path compute would make = senses to the situations where the aforementioned assumption does not hold.= What do you think?  

 

Thanks.

Young

 

 

 

From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 5:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

&nbs= p;

Hi all, 
 
when we talk about the stateful=
 path computation use case, it means IMHO that when a path has been calcula=
ted successfully in response to a request, a new path object is created in =
the data store. This does only make sense if the resources have been alloca=
ted in the TED of the PCE irrespective of the fact whether the connection a=
long this path will be established right away or at a later point in time. =
This will prevent further path computation requests from assuming that the =
resources are still available. As the TED of the PCE also has to reflect th=
e network state, I would assume that the network resources can be in one of=
 the following three states: available, allocatedButNotInUse,  allocat=
edAndInUse. The path objects also need state information reflecting for exa=
mple the alarm state of the allocated resources. The path calculated earlie=
r may become (temporarily) invalid due to a link failure affecting the path=
. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet<=
/span>
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “state”, are you referring to the YANG datast= ore or some other “interim” state of those paths that are calcu= lated but not instantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when th= e customer decided not to instantiate the TE tunnel (after the path compute= request).

 

Thanks.

Young

 

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider controller point of view COMPUTE_ONLY TE tunnels wil= l have exactly the same state as “normal” (COMPUTE_ADN_PROVISIO= N) TE tunnels.=

 

Igor

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would the YANG datastore be updated? I guess not. If not= , then the system/controller has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,<= /span>

You are exactly right. The purpose of the “compute-only” T= E tunnel is to create/maintain the normal TE tunnel state and (re-)compute = TE paths for the TE tunnel connections/LSPs but not signal/provision the LSPs.

 

Igor

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intention of defining „compute-only tunnels̶= 0; to create state in the controller, but not to signal them? If the tunnel= should be signaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both= variants, and both can be encoded in YANG. Is there anything I miss here?<= /span>

 

Michael

 

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you on your point. If we use rpc, it is clear. On th= e other hand, if we were to use “stateful compute-only” it seem= s that the system/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is th= at YANG datastore is updated only when the path is signaled and resource is= allocated. Would this give the system/controller additional burden to keep= the “interim” state?

 

Young

 

From: CCAMP [mail= to:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something, but to me, the domain controller either comput= es a path stateless, which can be modeled in YANG in an RPC. Or the domain = controller computes a path, stores state, and provides access to the result in the YANG datastore. In the latter cas= e, whether resources are allocated, or whether the NEs get actually provisi= oned, is an orthogonal question.

 

As a side note, I am not sure of I would call a domain controller or a= n NMS a PCE. Path computation is only a subset of the functions of a domain= controller.

 

Michael

 

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(N= okia - DE); Igor Bryskin; CCAMP (ccamp@ie= tf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you p= lease explain what the “stateful compute-only” stands for I don= ’t understand what is stateful in a path computation request only.

IMHO eith= er I ask the PCE (SDN controller, NMS, whatever) to compute a path and then= forget about it or I ask to compute and provision it. I don’t unders= tand the value of asking for it and remembering about it.

 

BR
Daniele 

 

From:<= /span> Scharf, Michael (Noki= a - DE) [mailto:michael.scharf@= nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this before. From an implementer’s perspective= , the two clean solutions to the problem seem to either stateful „com= pute-only“ tunnels or a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Comp= utation

 

 

   Work on extending the TE Tunnel YANG model to = support the need to<= /o:p>

   request path computation has recently started = also in the context of

   the [TE-TUN= NEL] draft.=

 

   It is possible to request path computation by = configuring a<= /span>

   "compute-only" TE tunnel and retriev= ing the computed path(s) in the

   LSP(s) Record-Route Object (RRO) list as descr= ibed in [TE-TUNNEL].

 

   This is a stateful solution since the state of= each created<= /span>

   "compute-only" TE tunnel needs to be= maintained and updated, when

   underlying network conditions change.

 

   The need also for a stateless solution, based = on an RPC, has been<= /o:p>

   recognized.

 

 

   The YANG model to support stateless RPC is for= further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

--_000_AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20AM4PR07MB1521eurp_-- From nobody Fri Nov 4 06:07:18 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA1E12940C; Fri, 4 Nov 2016 06:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kqWe-a0wqYI; Fri, 4 Nov 2016 06:07:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF811293DF; Fri, 4 Nov 2016 06:07:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZR58228; Fri, 04 Nov 2016 13:07:06 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 13:07:05 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 06:06:50 -0700 From: Igor Bryskin To: Leeyoung , "Scharf, Michael (Nokia - DE)" , Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" , "mpls@ietf.org" Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAnsUA Date: Fri, 4 Nov 2016 13:06:49 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F1C9@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581C87FB.0211, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626 Archived-At: Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:07:14 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Young, If the client does not want to keep a COMPUTE_ONLY TE tunnel state it can a= lways delete the state. Besides it will be possible to configure TE tunnel = in COMPUTE_AND_FORGET mode, in which the provider will automatically remove= the state as soon as it delivers the tunnel path computation results to th= e client. Furthermore, YANG global/action RPC makes sense when the path computation r= esults could be returned synchronously. If this is not possible or cannot b= e guaranteed for whatever reason (e.g. path computation takes some time, ne= eds to be requested from remote controller or PCE, etc.) RPC will also work= , but this will not be much different from configuring a TE tunnel in COMPU= TE_AND_FORGET mode, because the results will have to be delivered asynchron= ously using the regular client subscription (for the TE tunnel) notificati= on. Igor From: Leeyoung Sent: Thursday, November 03, 2016 4:12 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

If the client does not= want to keep a COMPUTE_ONLY TE tunnel state it can always delete the state= . Besides it will be possible to configure TE tunnel in COMPUTE_AND_FORGET = mode, in which the provider will automatically remove the state as soon as it delivers the tunnel path computation result= s to the client.

Furthermore, YANG glob= al/action RPC makes sense when the path computation results could be return= ed synchronously. If this is not possible or cannot be guaranteed for w= hatever reason (e.g. path computation takes some time, needs to be requeste= d from remote controller or PCE, etc.) RPC will also work, but this will no= t be much different from configuring a TE tunnel in COMPUTE_AND_FORGET mode, because the results will have to b= e delivered asynchronously using the regular client subscription (for the T= E tunnel)  notification.

 

 

Igor=

 

 

From: Leeyoung
Sent: Thursday, November 03, 2016 4:12 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Hi Michael,=

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= span lang=3D"IT">

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= span lang=3D"IT">

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].=

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.=

 

  = ; The need also for a stateless solution, based on an RPC, has been<= span lang=3D"IT">

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_-- From nobody Fri Nov 4 06:26:12 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFBF129470; Fri, 4 Nov 2016 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOpHIkngV-Bm; Fri, 4 Nov 2016 06:25:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7EF1294F2; Fri, 4 Nov 2016 06:25:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUM96569; Fri, 04 Nov 2016 13:25:45 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 13:25:43 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 06:25:30 -0700 From: Igor Bryskin To: "Beller, Dieter (Nokia - DE)" , Leeyoung Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujA= Date: Fri, 4 Nov 2016 13:25:30 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx>, <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.581C8C59.02FA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , "pce@ietf.org" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 13:25:55 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dieter,<= /span>

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.<= /o:p>

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.or= g
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi all, 
 
when we talk about the stateful path computati=
on use case, it means IMHO that when a path has been calculated successfull=
y in response to a request, a new path object is created in the data store.=
 This does only make sense if the resources have been allocated in the TED =
of the PCE irrespective of the fact whether the connection along this path =
will be established right away or at a later point in time. This will preve=
nt further path computation requests from assuming that the resources are s=
till available. As the TED of the PCE also has to reflect the network state=
, I would assume that the network resources can be in one of the following =
three states: available, allocatedButNotInUse,  allocatedAndInUse. The=
 path objects also need state information reflecting for example the alarm =
state of the allocated resources. The path calculated earlier may become (t=
emporarily) invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyoung@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6. =    YANG Model for requesting Path Computation

 

 

  = ; Work on extending the TE Tunnel YANG model to support the need to<= o:p>

  = ; request path computation has recently started also in the context of

  = ; the [TE-TUNNEL] draft.

 

  = ; It is possible to request path computation by configuring a

  = ; "compute-only" TE tunnel and retrieving the computed path(s) in= the

  = ; LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

 

  = ; This is a stateful solution since the state of each created

  = ; "compute-only" TE tunnel needs to be maintained and updated, wh= en

  = ; underlying network conditions change.

 

  = ; The need also for a stateless solution, based on an RPC, has been<= o:p>

  = ; recognized.

 

 

  = ; The YANG model to support stateless RPC is for further study.=

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1E1dfweml501mbx_-- From nobody Fri Nov 4 10:48:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6819129497; Fri, 4 Nov 2016 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBMlyD574GGf; Fri, 4 Nov 2016 10:48:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1394B129446; Fri, 4 Nov 2016 10:48:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 4DB2F131423F8; Fri, 4 Nov 2016 17:48:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA4HmXYI011290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Nov 2016 17:48:34 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA4HmXNX013436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Nov 2016 18:48:33 +0100 Received: from [149.204.106.204] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 4 Nov 2016 18:48:33 +0100 To: Igor Bryskin References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> From: Dieter Beller Organization: Nokia Message-ID: <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> Date: Fri, 4 Nov 2016 18:48:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 X-Originating-IP: [135.239.27.38] Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , Leeyoung , "pce@ietf.org" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:48:41 -0000 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD13aW5kb3dzLTEyNTIiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAg IEhpIElnb3IsPGJyPg0KICAgIDxicj4NCiAgICBjb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkg aG93IHVzZWZ1bCBhIHN0YXRlZnVsIHBhdGggPGI+d2l0aG91dA0KICAgICAgcmVzb3VyY2Ug YWxsb2NhdGlvbjwvYj4gaXMuIEkgY2FuJ3Qgc2VlIHRoZSBiZW5lZml0cyBvZiB0aGlzIHVz ZQ0KICAgIGNhc2UuPGJyPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgVGhhbmtzLDxicj4N CiAgICBEaWV0ZXI8YnI+DQogICAgPGJyPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+T24gMDQuMTEuMjAxNiAxNDoyNSwgSWdvciBCcnlza2luDQogICAgICB3cm90ZTo8 YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUNCiAgICAgIGNpdGU9Im1pZDowQzcy QzM4RTdFQkMzNDQ5OUU4QTlFN0REMDA3ODYzOTA4RjBGMUUxQGRmd2VtbDUwMS1tYngiDQog ICAgICB0eXBlPSJjaXRlIj4NCiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw ZSIgY29udGVudD0idGV4dC9odG1sOw0KICAgICAgICBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+ DQogICAgICA8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3Jk IDEyIChmaWx0ZXJlZA0KICAgICAgICBtZWRpdW0pIj4NCiAgICAgIDxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDYW1icmlhOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFk aW5nIDIgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUt bGluazoiSGVhZGluZyAyIjsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCglj b2xvcjojNEY4MUJEOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsMDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5iZXJzY2hy aWZ0MiwgbGkuYmVyc2NocmlmdDIsIGRpdi5iZXJzY2hyaWZ0Mg0KCXttc28tc3R5bGUtbmFt ZTpiZXJzY2hyaWZ0MjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0KcC5odG1sdm9yZm9ybWF0aWVydCwgbGkuaHRtbHZvcmZvcm1hdGllcnQsIGRpdi5o dG1sdm9yZm9ybWF0aWVydA0KCXttc28tc3R5bGUtbmFtZTpodG1sdm9yZm9ybWF0aWVydDsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5zcHJlY2hi bGFzZW50ZXh0LCBsaS5zcHJlY2hibGFzZW50ZXh0LCBkaXYuc3ByZWNoYmxhc2VudGV4dA0K CXttc28tc3R5bGUtbmFtZTpzcHJlY2hibGFzZW50ZXh0Ow0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb2NocGRlZmF1bHQsIGxpLm1zb2NocGRl ZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOm1zb2NocGRlZmF1 bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uaGVhZGluZzJjaGFyMA0KCXttc28tc3R5bGUtbmFtZTpoZWFkaW5nMmNoYXI7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4u aHRtbHByZWZvcm1hdHRlZGNoYXIwDQoJe21zby1zdHlsZS1uYW1lOmh0bWxwcmVmb3JtYXR0 ZWRjaGFyOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5iYWxsb29udGV4 dGNoYXIwDQoJe21zby1zdHlsZS1uYW1lOmJhbGxvb250ZXh0Y2hhcjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5iZXJzY2hyaWZ0MnpjaG4NCgl7bXNv LXN0eWxlLW5hbWU6YmVyc2NocmlmdDJ6Y2huOw0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwi c2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLmh0 bWx2b3Jmb3JtYXRpZXJ0emNobg0KCXttc28tc3R5bGUtbmFtZTpodG1sdm9yZm9ybWF0aWVy dHpjaG47DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5zcHJlY2hibGFzZW50ZXh0 emNobg0KCXttc28tc3R5bGUtbmFtZTpzcHJlY2hibGFzZW50ZXh0emNobjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjkNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTI5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmVtYWlsc3R5bGUzMA0KCXtt c28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMzA7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTMyDQoJe21z by1zdHlsZS1uYW1lOmVtYWlsc3R5bGUzMjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMzMNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTMzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmVtYWlsc3R5bGUzNA0KCXtt c28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMzQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTM1DQoJe21z by1zdHlsZS1uYW1lOmVtYWlsc3R5bGUzNTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMzYNCgl7bXNv LXN0eWxlLW5hbWU6ZW1haWxzdHlsZTM2Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGUzNw0KCXttc28t c3R5bGUtbmFtZTplbWFpbHN0eWxlMzc7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTM4DQoJe21zby1z dHlsZS1uYW1lOmVtYWlsc3R5bGUzODsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMzkNCgl7bXNvLXN0 eWxlLW5hbWU6ZW1haWxzdHlsZTM5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmVtYWlsc3R5bGU0MA0KCXttc28tc3R5 bGUtbmFtZTplbWFpbHN0eWxlNDA7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTQ0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQogICAgICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KICAgICAgICA8 ZGl2Pg0KICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAgIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAgICAgICAgICAgICAgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQogICAgICAgICAgICAgICAgPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0KICAgICAgICAgICAgICAg ICAgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQogICAgICAgICAgICAgICAg ICA8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlDQogICAg ICAgICAgICAgICAgICAgIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SGkNCiAgICAgICAgICAgICAgICAgICAgICAgIERpZXRlciw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPqA8L286cD48L3NwYW4+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+QQ0KICAgICAgICAgICAgICAgICAgICAgICAgcHJvdmlkZXIg bWF5IGNvbXB1dGUgcGF0aChzKSBmb3IgYSBURSB0dW5uZWwsDQogICAgICAgICAgICAgICAg ICAgICAgICBhbmQgdGhlbiAod2l0aG91dCBhbnkgcmVzb3VyY2UgYWxsb2NhdGlvbikgbWF5 DQogICAgICAgICAgICAgICAgICAgICAgICBzdGFydCBtb25pdG9yaW5nL2Vuc3VyaW5nIHRo ZSBwYXRoDQogICAgICAgICAgICAgICAgICAgICAgICB2YWxpZGl0eS9vcHRpbWFsaXR5IGJ5 IHJlLWNvbXB1dGluZyB0aGVtIGluIGFuDQogICAgICAgICAgICAgICAgICAgICAgICBldmVu dCBkcml2ZW4gbWFubmVyLiBGb3IgZXhhbXBsZSwgaXQgY2FuIHRyaWdnZXINCiAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSByZS1jb21wdXRhdGlvbiBvZiB0aGUgcGF0aChzKSB3aGVu IGRldGVjdGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgYSBjaGFuZ2UgaW4gYSBzdGF0 ZSBvZiBhIFRFIGxpbmsgdGhlIGN1cnJlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgIHBh dGgocykgYXJlIGdvaW5nIHRocm91Z2guoCBEZXBlbmRpbmcgb24gdGhlDQogICAgICAgICAg ICAgICAgICAgICAgICByZXN1bHRzIGFkZGl0aW9uYWwgbm90aWZpY2F0aW9ucyBtYXkgYmUg c2VudCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNsaWVudC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPqA8L286cD48L3NwYW4+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Tm90ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB0aGlz IGlzIGluIGFkZGl0aW9uIHRvIHRoZSByZWFzb25zIHlvdQ0KICAgICAgICAgICAgICAgICAg ICAgICAgY29ycmVjdGx5IGlkZW50aWZpZWQgZm9yIGltcGxlbWVudGluZyBzdGF0ZWZ1bA0K ICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCBjb21wdXRhdGlvbiAoc3VjaCBhcyBjb21w dXRlX2FuZF9yZXNlcnZlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPqA8L286cD48L3NwYW4+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklnb3I8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPqA8L286cD48L3NwYW4+PC9wPg0KICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD6gPC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAg ICAgICAgICAgICAgICAgICAgICAgIEJlbGxlciwgRGlldGVyIChOb2tpYSAtIERFKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQi IGhyZWY9Im1haWx0bzpkaWV0ZXIuYmVsbGVyQG5va2lhLmNvbSI+bWFpbHRvOmRpZXRlci5i ZWxsZXJAbm9raWEuY29tPC9hPl0NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIg MDMsIDIwMTYgNjoyNyBQTTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiPlRvOjwv Yj4gTGVleW91bmc8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5DYzo8L2I+IEln b3IgQnJ5c2tpbjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYQ0KICAgICAgICAgICAgICAgICAg ICAgICAgLSBERSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVANCiAgICAgICAgICAgICAg ICAgICAgICAgICg8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt YWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPik7IDxhIGNsYXNzPSJt b3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBj ZUBpZXRmLm9yZzwvYT47IFRFQVMgV0cNCiAgICAgICAgICAgICAgICAgICAgICAgICg8YSBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dGVhc0BpZXRm Lm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJl dmlhdGVkIiBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxz XQ0KICAgICAgICAgICAgICAgICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVl dGV4dCIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10 ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+oDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgYWxsLCA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD6gPC9vOnA+PC9zcGFuPjwv cHJlPg0KICAgICAgICAgICAgICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj53aGVuIHdlIHRhbGsgYWJvdXQgdGhlIHN0YXRlZnVsIHBh dGggY29tcHV0YXRpb24gdXNlIGNhc2UsIGl0IG1lYW5zIElNSE8gdGhhdCB3aGVuIGEgcGF0 aCBoYXMgYmVlbiBjYWxjdWxhdGVkIHN1Y2Nlc3NmdWxseSBpbiByZXNwb25zZSB0byBhIHJl cXVlc3QsIGEgbmV3IHBhdGggb2JqZWN0IGlzIGNyZWF0ZWQgaW4gdGhlIGRhdGEgc3RvcmUu IFRoaXMgZG9lcyBvbmx5IG1ha2Ugc2Vuc2UgaWYgdGhlIHJlc291cmNlcyBoYXZlIGJlZW4g YWxsb2NhdGVkIGluIHRoZSBURUQgb2YgdGhlIFBDRSBpcnJlc3BlY3RpdmUgb2YgdGhlIGZh Y3Qgd2hldGhlciB0aGUgY29ubmVjdGlvbiBhbG9uZyB0aGlzIHBhdGggd2lsbCBiZSBlc3Rh Ymxpc2hlZCByaWdodCBhd2F5IG9yIGF0IGEgbGF0ZXIgcG9pbnQgaW4gdGltZS4gVGhpcyB3 aWxsIHByZXZlbnQgZnVydGhlciBwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3RzIGZyb20gYXNz dW1pbmcgdGhhdCB0aGUgcmVzb3VyY2VzIGFyZSBzdGlsbCBhdmFpbGFibGUuIEFzIHRoZSBU RUQgb2YgdGhlIFBDRSBhbHNvIGhhcyB0byByZWZsZWN0IHRoZSBuZXR3b3JrIHN0YXRlLCBJ IHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBuZXR3b3JrIHJlc291cmNlcyBjYW4gYmUgaW4gb25l IG9mIHRoZSBmb2xsb3dpbmcgdGhyZWUgc3RhdGVzOiBhdmFpbGFibGUsIGFsbG9jYXRlZEJ1 dE5vdEluVXNlLKAgYWxsb2NhdGVkQW5kSW5Vc2UuIFRoZSBwYXRoIG9iamVjdHMgYWxzbyBu ZWVkIHN0YXRlIGluZm9ybWF0aW9uIHJlZmxlY3RpbmcgZm9yIGV4YW1wbGUgdGhlIGFsYXJt IHN0YXRlIG9mIHRoZSBhbGxvY2F0ZWQgcmVzb3VyY2VzLiBUaGUgcGF0aCBjYWxjdWxhdGVk IGVhcmxpZXIgbWF5IGJlY29tZSAodGVtcG9yYXJpbHkpIGludmFsaWQgZHVlIHRvIGEgbGlu ayBmYWlsdXJlIGFmZmVjdGluZyB0aGUgcGF0aC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQogICAgICAgICAgICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+oDwvbzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAg ICAgICAgICAgPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KICAg ICAgICAgICAgICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPqA8L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgICAg ICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+oDwvbzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLCA8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGlldGVyPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQogICAgICAgICAgICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+oDwvbzpwPjwvc3Bhbj48L3ByZT4NCiAg ICAgICAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+U2VudCBmcm9tIG15IHRhYmxldDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KICAgICAgICAgICAgICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPqA8L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAg ICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkxlZXlvdW5nIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1h aWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tIj4mbHQ7bGVleW91bmdAaHVhd2VpLmNvbSZndDs8 L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KICAgICAgICAgICAgICAgICAg ICA8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PqA8L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZ29yLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5XaGVuDQogICAgICAgICAgICAgICAgICAgICAgICB5b3Ugc2F5IJNz dGF0ZZQsIGFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoZSBZQU5HDQogICAgICAgICAgICAgICAg ICAgICAgICBkYXRhc3RvcmUgb3Igc29tZSBvdGhlciCTaW50ZXJpbZQgc3RhdGUgb2YgdGhv c2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHBhdGhzIHRoYXQgYXJlIGNhbGN1bGF0ZWQg YnV0IG5vdCBpbnN0YW50aWF0ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgIGFzIExTUHM/ IElmIHdlIHdlcmUgdG8gdXBkYXRlIHRoZSBZQU5HIGRhdGFzdG9yZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgZm9yIHRoaXMsIEkgd291bGQgdGhpbmsgdGhhdCB3ZSBtYXkgaGF2ZSBz b21lDQogICAgICAgICAgICAgICAgICAgICAgICBpc3N1ZSB3aGVuIHRoZSBjdXN0b21lciBk ZWNpZGVkIG5vdCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgaW5zdGFudGlhdGUgdGhl IFRFIHR1bm5lbCAoYWZ0ZXIgdGhlIHBhdGgNCiAgICAgICAgICAgICAgICAgICAgICAgIGNv bXB1dGUgcmVxdWVzdCkuDQogICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoYW5rcy48L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5Zb3VuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+ PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0K c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KICAgICAgICAgICAgICAgICAgICAgICAgSWdvciBCcnlz a2luDQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6MDIgUE08 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IExlZXlvdW5nOyBTY2hh cmYsIE1pY2hhZWwgKE5va2lhIC0NCiAgICAgICAgICAgICAgICAgICAgICAgIERFKTsgRGFu aWVsZSBDZWNjYXJlbGxpOyBDQ0FNUCAoPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZp YXRlZCIgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4p Ow0KICAgICAgICAgICAgICAgICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjsg VEVBUyBXRyAoPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFp bHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAg ICAgICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1h aWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDxiPlN1YmplY3Q6PC9iPiBSRToNCiAgICAgICAgICAgICAgICAgICAg ICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRp b24tMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15 YW5nLXBhdGgtY29tcHV0YXRpb24tMDA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48L3A+ DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5Zb3VuZyw8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RnJvbQ0K ICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHByb3ZpZGVyIGNvbnRyb2xsZXIgcG9pbnQg b2Ygdmlldw0KICAgICAgICAgICAgICAgICAgICAgICAgQ09NUFVURV9PTkxZIFRFIHR1bm5l bHMgd2lsbCBoYXZlIGV4YWN0bHkgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICBzYW1l IHN0YXRlIGFzIJNub3JtYWyUIChDT01QVVRFX0FETl9QUk9WSVNJT04pDQogICAgICAgICAg ICAgICAgICAgICAgICBURSB0dW5uZWxzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZ29y PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4N CnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIExl ZXlvdW5nDQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDM6NDIg UE08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IElnb3IgQnJ5c2tp bjsgU2NoYXJmLCBNaWNoYWVsIChOb2tpYQ0KICAgICAgICAgICAgICAgICAgICAgICAgLSBE RSk7IERhbmllbGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKDxhDQogICAgICAgICAgICAgICAgICAg ICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pOw0K ICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VA aWV0Zi5vcmc8L2E+Ow0KICAgICAgICAgICAgICAgICAgICAgICAgVEVBUyBXRyAoPGEgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJt YWlsdG86dGVhc0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAg ICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwv YT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUkU6IDxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAiPmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29t cHV0YXRpb24tMDA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48L3A+DQogICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JZ29yLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3Nw YW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Jbg0KICAgICAgICAgICAgICAg ICAgICAgICAgc3VjaCBjYXNlLCB3b3VsZCB0aGUgWUFORyBkYXRhc3RvcmUgYmUgdXBkYXRl ZD8NCiAgICAgICAgICAgICAgICAgICAgICAgIEkgZ3Vlc3Mgbm90LiBJZiBub3QsIHRoZW4g dGhlIHN5c3RlbS9jb250cm9sbGVyDQogICAgICAgICAgICAgICAgICAgICAgICBoYXMgdG8g a2VlcCB0aGlzIGludGVyaW0gc3RhdGUsIHdvdWxkIGl0Pw0KICAgICAgICAgICAgICAgICAg ICAgIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86 cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+WW91bmc8L3NwYW4+PG86cD48L286cD48L3A+DQogICAg ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K ICAgICAgICAgICAgICAgICAgICAgICAgSWdvciBCcnlza2luDQogICAgICAgICAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2IDI6MzQgUE08YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICA8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSk7DQogICAg ICAgICAgICAgICAgICAgICAgICBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBDQ0FN UCAoPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5v cmciPmNjYW1wQGlldGYub3JnPC9hPik7DQogICAgICAgICAgICAgICAgICAgICAgICA8YSBt b3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvYT47DQogICAgICAgICAgICAg ICAgICAgICAgICBURUFTIFdHICg8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAg ICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGll dGYub3JnPC9hPik7DQogICAgICAgICAgICAgICAgICAgICAgICA8YSBtb3otZG8tbm90LXNl bmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptcGxz QGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxiPlN1YmplY3Q6PC9iPiBSRTogPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmct cGF0aC1jb21wdXRhdGlvbi0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMDwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPqA8 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1pY2hhZWwsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91DQogICAgICAgICAgICAgICAgICAgICAgICBh cmUgZXhhY3RseSByaWdodC4gVGhlIHB1cnBvc2Ugb2YgdGhlDQogICAgICAgICAgICAgICAg ICAgICAgICCTY29tcHV0ZS1vbmx5lCBURSB0dW5uZWwgaXMgdG8gY3JlYXRlL21haW50YWlu DQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgbm9ybWFsIFRFIHR1bm5lbCBzdGF0ZSBh bmQgKHJlLSljb21wdXRlIFRFDQogICAgICAgICAgICAgICAgICAgICAgICBwYXRocyBmb3Ig dGhlIFRFIHR1bm5lbCBjb25uZWN0aW9ucy9MU1BzIGJ1dCBub3QNCiAgICAgICAgICAgICAg ICAgICAgICAgIHNpZ25hbC9wcm92aXNpb24gdGhlIExTUHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPklnb3I8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgU2NoYXJmLCBNaWNoYWVsIChOb2tpYSAtIERFKSBbPGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tIj5tYWls dG86bWljaGFlbC5zY2hhcmZAbm9raWEuY29tPC9hPl0NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTm92ZW1iZXIgMDMsIDIwMTYgMzoxNyBQTTxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxiPlRvOjwvYj4gTGVleW91bmc7IERhbmllbGUgQ2VjY2FyZWxsaTsgSWdvcg0KICAg ICAgICAgICAgICAgICAgICAgICAgQnJ5c2tpbjsgQ0NBTVAgKDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmNjYW1w QGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAgICAgICAgICAg ICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L2E+Ow0KICAgICAg ICAgICAgICAgICAgICAgICAgVEVBUyBXRyAoPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0K ICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86dGVhc0BpZXRmLm9yZyI+ dGVhc0BpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUkU6IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSINCmhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVh cy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDA8L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj6gPG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Jc26SdA0KICAgICAgICAg ICAgICAgICAgICAgICAgdGhlIGludGVudGlvbiBvZiBkZWZpbmluZyCEY29tcHV0ZS1vbmx5 IHR1bm5lbHOTDQogICAgICAgICAgICAgICAgICAgICAgICB0byBjcmVhdGUgc3RhdGUgaW4g dGhlIGNvbnRyb2xsZXIsIGJ1dCBub3QgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgIHNp Z25hbCB0aGVtPyBJZiB0aGUgdHVubmVsIHNob3VsZCBiZSBzaWduYWxlZA0KICAgICAgICAg ICAgICAgICAgICAgICAgYW5kIHJlc291cmNlcyBzaGFsbCBiZSBhbGxvY2F0ZWQsIHdoeSBu b3QganVzdA0KICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJlIGEgdmFuaWxsYSB0 dW5uZWw/IFVzZXMgY2FzZXMgc2VlbSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgZXhp c3QgZm9yIGJvdGggdmFyaWFudHMsIGFuZCBib3RoIGNhbiBiZSBlbmNvZGVkDQogICAgICAg ICAgICAgICAgICAgICAgICBpbiBZQU5HLiBJcyB0aGVyZSBhbnl0aGluZyBJIG1pc3MgaGVy ZT88L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiDQog ICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkRFIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ig0KICAgICAgICAgICAgICAgICAgICAgICAg bGFuZz0iREUiPiBMZWV5b3VuZyBbPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbSI+ bWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb208L2E+XQ0KICAgICAgICAgICAgICAgICAgICAg ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBOb3ZlbWJlciAwMywgMjAxNiA3OjQ5IFBNPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwgKE5va2lhIC0gREUpOyBEYW5pZWxlDQog ICAgICAgICAgICAgICAgICAgICAgICBDZWNjYXJlbGxpOyBJZ29yIEJyeXNraW47IENDQU1Q ICg8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi DQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9y ZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i bWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjsNCiAgICAgICAgICAgICAg ICAgICAgICAgIFRFQVMgV0cgKDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciPnRlYXNAaWV0 Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgPGI+U3ViamVjdDo8L2I+IFJFOiA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQpocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1w YXRoLWNvbXB1dGF0aW9uLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i dXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iREUiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I aQ0KICAgICAgICAgICAgICAgICAgICAgICAgTWljaGFlbCw8L3NwYW4+PG86cD48L286cD48 L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SQ0KICAgICAgICAgICAgICAgICAgICAgICAgdGhpbmsgSSBhbSB3aXRoIHlvdSBv biB5b3VyIHBvaW50LiBJZiB3ZSB1c2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHJwYywg aXQgaXMgY2xlYXIuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSB3ZXJlDQogICAgICAgICAg ICAgICAgICAgICAgICB0byB1c2Ugk3N0YXRlZnVsIGNvbXB1dGUtb25seZQgaXQgc2VlbXMg dGhhdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgIHN5c3RlbS9jb250cm9sbGVyIGhh cyB0byBrZWVwIHRoZSBzdGF0ZSBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgIHBh dGhzIHNvbWV3aGVyZSB3aGljaCBpcyBub3QgWUFORyBkYXRhc3RvcmUuIE15DQogICAgICAg ICAgICAgICAgICAgICAgICB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgWUFORyBkYXRhc3RvcmUg aXMgdXBkYXRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgb25seSB3aGVuIHRoZSBwYXRo IGlzIHNpZ25hbGVkIGFuZCByZXNvdXJjZSBpcw0KICAgICAgICAgICAgICAgICAgICAgICAg YWxsb2NhdGVkLiBXb3VsZCB0aGlzIGdpdmUgdGhlIHN5c3RlbS9jb250cm9sbGVyDQogICAg ICAgICAgICAgICAgICAgICAgICBhZGRpdGlvbmFsIGJ1cmRlbiB0byBrZWVwIHRoZSCTaW50 ZXJpbZQgc3RhdGU/DQogICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPllvdW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAgICAgICAgICAgICAg ICAgICAgICAgIENDQU1QIFs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQogICAgICAgICAgICAgICAgICAg ICAgICA8Yj5PbiBCZWhhbGYgT2YgPC9iPlNjaGFyZiwgTWljaGFlbCAoTm9raWEgLQ0KICAg ICAgICAgICAgICAgICAgICAgICAgREUpPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg PGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAwMywgMjAxNiA4OjU4IEFNPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgPGI+VG86PC9iPiBEYW5pZWxlIENlY2NhcmVsbGk7 IElnb3IgQnJ5c2tpbjsNCiAgICAgICAgICAgICAgICAgICAgICAgIENDQU1QICg8YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1h aWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAg ICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9h PjsNCiAgICAgICAgICAgICAgICAgICAgICAgIFRFQVMgV0cgKDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNA aWV0Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAg IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIDxhDQog ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCmhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBh dGgtY29tcHV0YXRpb24tMDAiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1 c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDA8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86 cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NYXliZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgSSBtaXNzIHNvbWV0aGluZywgYnV0IHRvIG1lLCB0aGUgZG9tYWluDQogICAgICAg ICAgICAgICAgICAgICAgICBjb250cm9sbGVyIGVpdGhlciBjb21wdXRlcyBhIHBhdGggc3Rh dGVsZXNzLA0KICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggY2FuIGJlIG1vZGVsZWQg aW4gWUFORyBpbiBhbiBSUEMuIE9yIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgZG9t YWluIGNvbnRyb2xsZXIgY29tcHV0ZXMgYSBwYXRoLCBzdG9yZXMgc3RhdGUsDQogICAgICAg ICAgICAgICAgICAgICAgICBhbmQgcHJvdmlkZXMgYWNjZXNzIHRvIHRoZSByZXN1bHQgaW4g dGhlIFlBTkcNCiAgICAgICAgICAgICAgICAgICAgICAgIGRhdGFzdG9yZS4gSW4gdGhlIGxh dHRlciBjYXNlLCB3aGV0aGVyIHJlc291cmNlcw0KICAgICAgICAgICAgICAgICAgICAgICAg YXJlIGFsbG9jYXRlZCwgb3Igd2hldGhlciB0aGUgTkVzIGdldCBhY3R1YWxseQ0KICAgICAg ICAgICAgICAgICAgICAgICAgcHJvdmlzaW9uZWQsIGlzIGFuIG9ydGhvZ29uYWwgcXVlc3Rp b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzDQogICAgICAgICAgICAgICAgICAgICAg ICBhIHNpZGUgbm90ZSwgSSBhbSBub3Qgc3VyZSBvZiBJIHdvdWxkIGNhbGwgYQ0KICAgICAg ICAgICAgICAgICAgICAgICAgZG9tYWluIGNvbnRyb2xsZXIgb3IgYW4gTk1TIGEgUENFLiBQ YXRoDQogICAgICAgICAgICAgICAgICAgICAgICBjb21wdXRhdGlvbiBpcyBvbmx5IGEgc3Vi c2V0IG9mIHRoZSBmdW5jdGlvbnMgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgIGEgZG9t YWluIGNvbnRyb2xsZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+ PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogICAgICAg ICAgICAgICAgICAgICAgICBEYW5pZWxlIENlY2NhcmVsbGkgWzxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmRhbmll bGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20iPm1haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tPC9hPl0NCiAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMDMs IDIwMTYgMjo0OSBQTTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiPlRvOjwvYj4g U2NoYXJmLCBNaWNoYWVsIDwvc3Bhbj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi DQogICAgICAgICAgICAgICAgICAgICAgICBsYW5nPSJERSI+KE5va2lhIC0gREUpOyBJZ29y IEJyeXNraW47IENDQU1QICg8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8t bm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0 bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAg ICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAg ICAgICAgICAgaHJlZj0ibWFpbHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9hPjsN CiAgICAgICAgICAgICAgICAgICAgICAgIFRFQVMgV0cgKDxhIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+KTsNCiAgICAgICAgICAgICAgICAgICAgICAgIDxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJFOiA8YSBtb3otZG8tbm90LXNl bmQ9InRydWUiDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNp YmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwPC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcGxlYXNl IGV4cGxhaW4gd2hhdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICCTc3RhdGVmdWwgY29t cHV0ZS1vbmx5lCBzdGFuZHMgZm9yIEkgZG9uknQNCiAgICAgICAgICAgICAgICAgICAgICB1 bmRlcnN0YW5kIHdoYXQgaXMgc3RhdGVmdWwgaW4gYSBwYXRoIGNvbXB1dGF0aW9uDQogICAg ICAgICAgICAgICAgICAgICAgcmVxdWVzdCBvbmx5Lg0KICAgICAgICAgICAgICAgICAgICAg IDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj5JTUhPIGVpdGhlciBJIGFzayB0aGUgUENFIChTRE4NCiAgICAgICAgICAgICAgICAg ICAgICBjb250cm9sbGVyLCBOTVMsIHdoYXRldmVyKSB0byBjb21wdXRlIGEgcGF0aCBhbmQN CiAgICAgICAgICAgICAgICAgICAgICB0aGVuIGZvcmdldCBhYm91dCBpdCBvciBJIGFzayB0 byBjb21wdXRlIGFuZA0KICAgICAgICAgICAgICAgICAgICAgIHByb3Zpc2lvbiBpdC4gSSBk b26SdCB1bmRlcnN0YW5kIHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICAgICAgIGFz a2luZyBmb3IgaXQgYW5kIHJlbWVtYmVyaW5nIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48 L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkJSPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgIERhbmllbGWgIDxvOnA+PC9vOnA+PC9wPg0KICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj6gPG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBT Y2hhcmYsIE1pY2hhZWwNCiAgICAgICAgICAgICAgICAgICAgICAoTm9raWEgLSBERSkgWzxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzptaWNoYWVsLnNjaGFyZkBub2tpYS5jb20iPm1haWx0bzptaWNoYWVsLnNjaGFy ZkBub2tpYS5jb208L2E+XQ0KICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gZ2lvdmVk7CAzIG5vdmVtYnJlIDIwMTYgMTQ6 NDU8YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGI+VG86PC9iPiBJZ29yIEJyeXNraW4g Jmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi DQogICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86SWdvci5Ccnlza2luQGh1 YXdlaS5jb20iPklnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPC9hPiZndDs7DQogICAgICAgICAg ICAgICAgICAgICAgRGFuaWVsZSBDZWNjYXJlbGxpICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9 InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86ZGFuaWVsZS5j ZWNjYXJlbGxpQGVyaWNzc29uLmNvbSI+ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNv bTwvYT4mZ3Q7Ow0KICAgICAgICAgICAgICAgICAgICAgIENDQU1QICg8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86Y2Nh bXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPikNCiAgICAgICAgICAgICAgICAgICAg ICAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAg ICAgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4mZ3Q7 Ow0KICAgICAgICAgICAgICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAg ICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPg0KICAg ICAgICAgICAgICAgICAgICAgICAgcGNlQGlldGYub3JnPC9hPjsgVEVBUyBXRyAoPGENCiAg ICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGlldGYu b3JnPC9hPikNCiAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciPnRlYXNAaWV0Zi5vcmc8L2E+Jmd0OzsNCiAgICAgICAgICAgICAgICAgICAgICA8 YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAgICAgICAgICAgICAgICAgICBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgPGI+U3ViamVjdDo8L2I+IFJFOiA8YSBtb3otZG8tbm90LXNlbmQ9 InRydWUiDQpocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idXNpYmVs LXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1idXNpYmVsLXRlYXMteWFuZy1wYXRoLWNvbXB1dGF0aW9uLTAwPC9hPjxv OnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJJVCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPldlDQogICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGRpc2N1c3NlZCB0aGlzIGJl Zm9yZS4gRnJvbSBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgaW1wbGVtZW50ZXKScyBw ZXJzcGVjdGl2ZSwgdGhlIHR3byBjbGVhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc29s dXRpb25zIHRvIHRoZSBwcm9ibGVtIHNlZW0gdG8gZWl0aGVyIHN0YXRlZnVsDQogICAgICAg ICAgICAgICAgICAgICAgICCEY29tcHV0ZS1vbmx5kyB0dW5uZWxzIG9yIGEgc3RhdGVsZXNz IFJQQy48L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPqA8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bhbg0Kc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi DQogICAgICAgICAgICAgICAgICAgICAgICAgIGxhbmc9IkRFIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4NCnN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ig0KICAgICAgICAgICAgICAgICAgICAg ICAgbGFuZz0iREUiPiBtcGxzIFs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiDQogICAgICAg ICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KICAgICAgICAgICAgICAgICAg ICAgICAgPGI+T24gQmVoYWxmIE9mIDwvYj5JZ29yIEJyeXNraW48YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICA8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAzLCAyMDE2 IDI6MzQgUE08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IERhbmll bGUgQ2VjY2FyZWxsaTsgQ0NBTVAgKDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i bWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT4pOw0KICAgICAgICAg ICAgICAgICAgICAgICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8 L2E+Ow0KICAgICAgICAgICAgICAgICAgICAgICAgVEVBUyBXRyAoPGEgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86dGVh c0BpZXRmLm9yZyI+dGVhc0BpZXRmLm9yZzwvYT4pOw0KICAgICAgICAgICAgICAgICAgICAg ICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gW0FMVV0gW21wbHNdPGEN CiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnVzaWJlbC10ZWFzLXlhbmct cGF0aC1jb21wdXRhdGlvbi0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YnVzaWJlbC10ZWFzLXlhbmctcGF0aC1jb21wdXRhdGlvbi0wMDwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkRFIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZyb20NCiAgICAgICAgICAgICAgICAgICAg ICAgIHRoZSBkcmFmdDo8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj6g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+Ni6goKAgWUFORyBNb2Rl bCBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgcmVxdWVzdGluZyBQYXRoIENvbXB1 dGF0aW9uPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAg ICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIN CiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAg TmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAg ICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+ oKAgV29yayBvbiBleHRlbmRpbmcgdGhlIFRFDQogICAgICAgICAgICAgICAgICAgICAgICBU dW5uZWwgWUFORyBtb2RlbCB0byBzdXBwb3J0IHRoZSBuZWVkIHRvPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAg ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcm cXVvdDsiIGxhbmc9IkVOIj6goCByZXF1ZXN0IHBhdGggY29tcHV0YXRpb24NCiAgICAgICAg ICAgICAgICAgICAgICAgIGhhcyByZWNlbnRseSBzdGFydGVkIGFsc28gaW4gdGhlIGNvbnRl eHQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAg ICAgICAgICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqCgIHRoZSBbPGENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgt Y29tcHV0YXRpb24tMDAjcmVmLVRFLVRVTk5FTCINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgdGl0bGU9IiZxdW90O0EgWUFORyBEYXRhIE1vZGVsIGZvciBUcmFmZmljDQogICAgICAg ICAgICAgICAgICAgICAgICAgIEVuZ2luZWVyaW5nIFR1bm5lbHMgYW5kIEludGVyZmFjZXMm cXVvdDsiPlRFLVRVTk5FTDwvYT5dDQogICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC48 L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAg ICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqA8L3NwYW4+PG86cD48L286cD48L3A+ DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgIE5ldyZxdW90OyIg bGFuZz0iRU4iPqCgIEl0IGlzIHBvc3NpYmxlIHRvDQogICAgICAgICAgICAgICAgICAgICAg ICByZXF1ZXN0IHBhdGggY29tcHV0YXRpb24gYnkgY29uZmlndXJpbmcgYTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCIN CiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAg TmV3JnF1b3Q7IiBsYW5nPSJFTiI+oKAgImNvbXB1dGUtb25seSIgVEUgdHVubmVsDQogICAg ICAgICAgICAgICAgICAgICAgICBhbmQgcmV0cmlldmluZyB0aGUgY29tcHV0ZWQgcGF0aChz KSBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAg ICAgICAgICAgICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqCgIExTUChzKSBSZWNv cmQtUm91dGUNCiAgICAgICAgICAgICAgICAgICAgICAgIE9iamVjdCAoUlJPKSBsaXN0IGFz IGRlc2NyaWJlZCBpbiBbPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJ1c2liZWwtdGVhcy15YW5nLXBhdGgtY29tcHV0YXRpb24tMDAjcmVmLVRFLVRVTk5FTCIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgdGl0bGU9IiZxdW90O0EgWUFORyBEYXRhIE1v ZGVsIGZvciBUcmFmZmljDQogICAgICAgICAgICAgICAgICAgICAgICAgIEVuZ2luZWVyaW5n IFR1bm5lbHMgYW5kIEludGVyZmFjZXMmcXVvdDsiPlRFLVRVTk5FTDwvYT5dLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAg ICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJF TiI+oKAgVGhpcyBpcyBhIHN0YXRlZnVsDQogICAgICAgICAgICAgICAgICAgICAgICBzb2x1 dGlvbiBzaW5jZSB0aGUgc3RhdGUgb2YgZWFjaCBjcmVhdGVkPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAg ICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVv dDsiIGxhbmc9IkVOIj6goCAiY29tcHV0ZS1vbmx5IiBURSB0dW5uZWwNCiAgICAgICAgICAg ICAgICAgICAgICAgIG5lZWRzIHRvIGJlIG1haW50YWluZWQgYW5kIHVwZGF0ZWQsIHdoZW48 L3NwYW4+PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAg ICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4iPqCgIHVuZGVybHlpbmcgbmV0d29yaw0K ICAgICAgICAgICAgICAgICAgICAgICAgY29uZGl0aW9ucyBjaGFuZ2UuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0K ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBO ZXcmcXVvdDsiIGxhbmc9IkVOIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAg IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiIGxhbmc9IkVOIj6g oCBUaGUgbmVlZCBhbHNvIGZvciBhDQogICAgICAgICAgICAgICAgICAgICAgICBzdGF0ZWxl c3Mgc29sdXRpb24sIGJhc2VkIG9uIGFuIFJQQywgaGFzIGJlZW48L3NwYW4+PG86cD48L286 cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAg ICAgICAgICAgICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4NCiAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgIE5ldyZx dW90OyIgbGFuZz0iRU4iPqCgIHJlY29nbml6ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuDQogICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiIGxh bmc9IkVOIj6gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAg ICAgICAgICAgICAgICAgICAgICBOZXcmcXVvdDsiIGxhbmc9IkVOIj6gPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0K ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICBO ZXcmcXVvdDsiIGxhbmc9IkVOIj6goCBUaGUgWUFORyBtb2RlbCB0bw0KICAgICAgICAgICAg ICAgICAgICAgICAgc3VwcG9ydCBzdGF0ZWxlc3MgUlBDIGlzIGZvciBmdXJ0aGVyIHN0dWR5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAg ICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAg ICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0K ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7 IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0K ICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAg ICAgTmV3JnF1b3Q7IiBsYW5nPSJFTiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAg ICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJF TiI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCINCiAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAg ICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIiBsYW5nPSJFTiI+SUImZ3Q7 Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgPGI+UGxlYXNlLCBub3RlLCB0aGF0IGlu IHRoZSBURSBUdW5uZWwgbW9kZWwgd2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29u c2lkZXIgdGhlIENPTVBVVEVfQU5EX0ZPUkdFVCBtb2RlLiBXZSBhbHNvDQogICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnNpZGVyIHRoZSBjb25jZXB0IG9mIHBhdGggY29tcHV0YXRp b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9uIHRvIGJlIGRlZmluZWQgdW5k ZXIgdGhlIFRFIHR1bm5lbCBub2RlLg0KICAgICAgICAgICAgICAgICAgICAgICAgICBBbGwg dGhpcyBpcyB0byBmYWNpbGl0YXRlIHN0YXRlbGVzcyBwYXRoDQogICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbXB1dGF0aW9ucy48L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KICAg ICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxzcGFuDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIiBsYW5nPSJFTiI+oDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAg ICAgICAgICAgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGI+PHNwYW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBOZXcmcXVv dDs7Y29sb3I6YmxhY2siIGxhbmc9IkVOIj5DaGVlcnMsPC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCINCiAgICAg ICAgICAgICAgICAgICAgICBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48Yj48 c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICAgICAgICAg IE5ldyZxdW90Oztjb2xvcjpibGFjayIgbGFuZz0iRU4iPklnb3I8L3NwYW4+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+oDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCiAg ICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD6gPC9vOnA+PC9w Pg0KICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD6gPC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8 L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogIDwv Ym9keT4NCjwvaHRtbD4NCg== From nobody Fri Nov 4 11:12:25 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3981295FB; Fri, 4 Nov 2016 11:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1p3l84WWSvF; Fri, 4 Nov 2016 11:12:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2332129446; Fri, 4 Nov 2016 11:12:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUN29582; Fri, 04 Nov 2016 18:12:11 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 18:12:10 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 11:12:00 -0700 From: Igor Bryskin To: Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAJcgAgACAujCAAMOrgP//jARQ Date: Fri, 4 Nov 2016 18:11:59 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> In-Reply-To: <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.254.206] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.581CCF7C.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 722aff6d616c510e0ca958addbcaa3a0 Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "TEAS WG \(teas@ietf.org\)" , Leeyoung , "pce@ietf.org" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:12:19 -0000 --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dieter,

 

A client may ask for a= path not to be used immediately (e.g. to present as an abstract TE link to= its own client, in some failure restoration scheme or as a part of disaste= r recovery network topology re-configuration) without committing any network resources. In this case the client would wa= nt to know at least  if/when the path has stopped being feasible any l= onger or (ideally) a better path is available.

 

This is similar to exp= osing to a client an abstract TE topology with an uncommitted abstract TE l= ink (i.e. TE link that does not have a committed TE tunnel supporting it an= d advertises potentiality). Once such link is provided, the provider is expected to send updates when/if the TE = link attributes change. For uncommitted/potential TE link such updates coul= d be provided based on event driven re-computation of the potentiality the = TE link represents.

The point is that an u= ncommitted abstract TE link and COMPUTE_ONLY TE tunnel can represent (each = in its own way) the same network potentiality

 

Cheers,

Igor=

 

 

 

From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-ya= ng-path-computation-00

 

Hi Igor,

could you please clarify how useful a stateful path without resource all= ocation is. I can't see the benefits of this use case.


Thanks,
Dieter

On 04.11.2016 14:25, Igor Bryskin wrote:<= /p>

Hi Dieter,=

 

A provider may compute= path(s) for a TE tunnel, and then (without any resource allocation) may st= art monitoring/ensuring the path validity/optimality by re-computing them i= n an event driven manner. For example, it can trigger the re-computation of the path(s) when detecting a change i= n a state of a TE link the current path(s) are going through.  Dependi= ng on the results additional notifications may be sent to the client.

 

Note that this is in a= ddition to the reasons you correctly identified for implementing stateful p= ath computation (such as compute_and_reserve).

 

Cheers,

Igor=

 

 

From: Beller, = Dieter (Nokia - DE) [mailto:diet= er.beller@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi all, 
 
when we talk about the stateful path computation use case,=
 it means IMHO that when a path has been calculated successfully in respons=
e to a request, a new path object is created in the data store. This does o=
nly make sense if the resources have been allocated in the TED of the PCE i=
rrespective of the fact whether the connection along this path will be esta=
blished right away or at a later point in time. This will prevent further p=
ath computation requests from assuming that the resources are still availab=
le. As the TED of the PCE also has to reflect the network state, I would as=
sume that the network resources can be in one of the following three states=
: available, allocatedButNotInUse,  allocatedAndInUse. The path object=
s also need state information reflecting for example the alarm state of the=
 allocated resources. The path calculated earlier may become (temporarily) =
invalid due to a link failure affecting the path. 
 
Does this make sense? 
 
 
Thanks, 
Dieter
 
Sent from my tablet
 
Leeyoung <leeyou=
ng@huawei.com> wrote:
 

Igor,

 

When you say “st= ate”, are you referring to the YANG datastore or some other “in= terim” state of those paths that are calculated but not instantiated = as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to i= nstantiate the TE tunnel (after the path compute request).

 

Thanks.

Young

 

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 3:02 PM
To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Young,

 

From the provider cont= roller point of view COMPUTE_ONLY TE tunnels will have exactly the same sta= te as “normal” (COMPUTE_ADN_PROVISION) TE tunnels.<= /o:p>

 

Igor=

 

From: Leeyoung
Sent: Thursday, November 03, 2016 3:42 PM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Igor,

 

In such case, would th= e YANG datastore be updated? I guess not. If not, then the system/controlle= r has to keep this interim state, would it?

 

Thanks.

Young

 

From: Igor Bry= skin
Sent: Thursday, November 03, 2016 2:34 PM
To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAM= P (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Michael,

You are exactly right.= The purpose of the “compute-only” TE tunnel is to create/maint= ain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel = connections/LSPs but not signal/provision the LSPs.

 

Igor=

 

From: Scharf, = Michael (Nokia - DE) [mailto:mi= chael.scharf@nokia.com]
Sent: Thursday, November 03, 2016 3:17 PM
To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Isn’t the intent= ion of defining „compute-only tunnels“ to create state in the c= ontroller, but not to signal them? If the tunnel should be signaled and res= ources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encode= d in YANG. Is there anything I miss here?

 

Michael

 

 

From: Leeyoung [mailto:lee= young@huawei.com]
Sent: Thursday, November 03, 2016 7:49 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; = CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Hi Michael,

 

I think I am with you = on your point. If we use rpc, it is clear. On the other hand, if we were to= use “stateful compute-only” it seems that the system/controlle= r has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated = only when the path is signaled and resource is allocated. Would this give t= he system/controller additional burden to keep the “interim” st= ate?

 

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Maybe I miss something= , but to me, the domain controller either computes a path stateless, which = can be modeled in YANG in an RPC. Or the domain controller computes a path,= stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources ar= e allocated, or whether the NEs get actually provisioned, is an orthogonal = question.

 

As a side note, I am n= ot sure of I would call a domain controller or an NMS a PCE. Path computati= on is only a subset of the functions of a domain controller.

 

Michael

 

 

 

From: Daniele = Ceccarelli [mailto:danie= le.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
To: Scharf, Michael
(Nokia - DE); Igo= r Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= /span>

 

Can you please explain what the “stateful comp= ute-only” stands for I don’t understand what is stateful in a p= ath computation request only.

IMHO either I ask the PCE (SDN controller, NMS, what= ever) to compute a path and then forget about it or I ask to compute and pr= ovision it. I don’t understand the value of asking for it and remembe= ring about it.

 

BR
Daniele 

 

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: gioved=EC 3 novembre 2016 14:45
To: Igor Bryskin <Igor= .Bryskin@huawei.com>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; CCAMP = (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00<= o:p>

 

We have discussed this= before. From an implementer’s perspective, the two clean solutions t= o the problem seem to either stateful „compute-only“ tunnels or= a stateless RPC.

 

Michael

 

 

From: mpls [mailto:mpls-= bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cca= mp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibe= l-teas-yang-path-computation-00

 

Hi,<= /p>

 

From the draft:=

 

6.    YANG Model for requesting Path Computation

 

 

   Work on extending the TE Tunnel YANG model to support t= he need to

   request path computation has recently started also in t= he context of

   the [TE-TUNN= EL] draft.

 

   It is possible to request path computation by configuri= ng a

   "compute-only" TE tunnel and retrieving the c= omputed path(s) in the

   LSP(s) Record-Route Object (RRO) list as described in [= TE-TUNN= EL].

 

   This is a stateful solution since the state of each cre= ated

   "compute-only" TE tunnel needs to be maintain= ed and updated, when

   underlying network conditions change.=

 

   The need also for a stateless solution, based on an RPC= , has been

   recognized.

 

 

   The YANG model to support stateless RPC is for further = study.

 

 

 

 

 

IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FO= RGET mode. We also consider the concept of path computation action to be de= fined under the TE tunnel node. All this is to facilitate stateless path co= mputations.

 

Cheers,

Igor

 

 

 

 

--_000_0C72C38E7EBC34499E8A9E7DD007863908F0F242dfweml501mbx_-- From nobody Sun Nov 6 21:26:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B2129B99; Sun, 6 Nov 2016 21:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7Zbf6557BhS; Sun, 6 Nov 2016 21:26:03 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26676129B88; Sun, 6 Nov 2016 21:26:03 -0800 (PST) Received: from [192.168.1.8] (unknown [49.146.58.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 98DB118013DA; Mon, 7 Nov 2016 06:25:57 +0100 (CET) To: "mpls@ietf.org" , "draft-ietf-mpls-tp-aps-updates@ietf.org" From: Loa Andersson Message-ID: <35e17fc3-fc6f-2ae6-5eda-bda8624250e6@pi.nu> Date: Mon, 7 Nov 2016 13:25:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-tp-aps-updates X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 05:26:04 -0000 Working Group, We are currently preparing draft-ietf-mpls-tp-aps-updates-01 for working group last call. We will do an IPR poll prior to the wglc. This is to start the IPR Poll. Are you aware of any IPR that applies to draft-ietf-mpls-tp-aps-updates? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is no IPR disclosure filed directly against this documents. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair PS I've resent this mail, apologies to those of you that got it twice. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Nov 6 23:47:28 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3461299AC; Sun, 6 Nov 2016 23:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.397 X-Spam-Level: X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xzNR3IQWjrR; Sun, 6 Nov 2016 23:47:25 -0800 (PST) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B25129CB1; Sun, 6 Nov 2016 23:47:25 -0800 (PST) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 7 Nov 2016 16:47:21 +0900 Received: from SMTP2.etri.info ([169.254.2.91]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Mon, 7 Nov 2016 16:47:21 +0900 From: "Ryoo, Jeong-dong " To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-tp-aps-updates@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-tp-aps-updates Thread-Index: AQHSOLdxWywuYWA+y0aLt4o5leqD/6DNIrK+ Date: Mon, 7 Nov 2016 07:47:21 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A29236252@SMTP2.etri.info> References: <35e17fc3-fc6f-2ae6-5eda-bda8624250e6@pi.nu> In-Reply-To: <35e17fc3-fc6f-2ae6-5eda-bda8624250e6@pi.nu> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZyA= x-originating-ip: [129.254.28.42] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29236252SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-tp-aps-updates X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 07:47:27 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29236252SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9hLA0KDQoNCk5vLCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBk b2N1bWVudC4NCg0KDQpKZW9uZy1kb25nDQoNCg0KUC5TLiBJIGFtIHNlbmRpbmcgdGhpcyBlbWFp bCBhZ2FpbiBhcyB0aGUgcHJldmlvdXMgZW1haWwgd2FzIGRlbGl2ZXJlZCB0byBhIGxpbWl0ZWQg c2V0IG9mIHJlY2lwaWVudHMuDQoNCiAgICAgICBNeSBhcHBvbG9naWVzIGlmIHlvdSByZWNlaXZl ZCB0d2ljZS4NCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CuuztOuCuCDsgqzrnowgOiAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udT4NCuuztOuCuCDrgqDs p5wgOiAyMDE2LTExLTA3IDE0OjI2OjA3ICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiBtcGxz QGlldGYub3JnIDxtcGxzQGlldGYub3JnPiwgZHJhZnQtaWV0Zi1tcGxzLXRwLWFwcy11cGRhdGVz QGlldGYub3JnIDxkcmFmdC1pZXRmLW1wbHMtdHAtYXBzLXVwZGF0ZXNAaWV0Zi5vcmc+DQrssLjs obAgOiBtcGxzLWNoYWlyc0BpZXRmLm9yZyA8bXBscy1jaGFpcnNAaWV0Zi5vcmc+LCBEZWJvcmFo IEEgQnJ1bmdhcmQgPGRiMzU0NkBhdHQuY29tPg0K7KCc66qpIDogSVBSIHBvbGwgb24gZHJhZnQt aWV0Zi1tcGxzLXRwLWFwcy11cGRhdGVzDQoNCg0KDQpXb3JraW5nIEdyb3VwLA0KDQoNCg0KDQoN CldlIGFyZSBjdXJyZW50bHkgcHJlcGFyaW5nIGRyYWZ0LWlldGYtbXBscy10cC1hcHMtdXBkYXRl cy0wMSBmb3Igd29ya2luZw0KDQoNCg0KZ3JvdXAgbGFzdCBjYWxsLiBXZSB3aWxsIGRvIGFuIElQ UiBwb2xsIHByaW9yIHRvIHRoZSB3Z2xjLg0KDQoNCg0KDQoNClRoaXMgaXMgdG8gc3RhcnQgdGhl IElQUiBQb2xsLg0KDQoNCg0KDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp ZXMgdG8gZHJhZnQtaWV0Zi1tcGxzLXRwLWFwcy11cGRhdGVzPw0KDQoNCg0KDQoNCklmIHNvLCBo YXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1 bGVzDQoNCg0KDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS4NCg0KDQoNCg0KDQpUaGVyZSBpcyBubyBJUFIgZGlzY2xvc3VyZSBmaWxlZCBkaXJl Y3RseSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnRzLg0KDQoNCg0KDQoNCklmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQoN Cg0KDQp0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgcmVsZXZhbnQNCg0KDQoNCklQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBz ZW50IHRvIHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZQ0KDQoNCg0KZG9jdW1lbnQgd2ls bCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVu DQoNCg0KDQpyZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KDQoN Cg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlz dGVkIGFzIGFuIGF1dGhvciBvcg0KDQoNCg0KY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxp Y2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55DQoNCg0KDQpJUFIgdGhh dCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVs ZXMuDQoNCg0KDQoNCg0KL0xvYQ0KDQoNCg0KbXBscyB3ZyBjby1jaGFpcg0KDQoNCg0KDQoNClBT DQoNCg0KDQpJJ3ZlIHJlc2VudCB0aGlzIG1haWwsIGFwb2xvZ2llcyB0byB0aG9zZSBvZiB5b3Ug dGhhdCBnb3QgaXQgdHdpY2UuDQoNCg0KDQoNCg0KLS0NCg0KDQoNCg0KDQoNCg0KTG9hIEFuZGVy c3NvbiBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQoNCg0KDQpTZW5pb3IgTVBMUyBFeHBl cnQgbG9hQHBpLm51DQoNCg0KDQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSBwaG9u ZTogKzQ2IDczOSA4MSAyMSA2NA0KDQoNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29236252SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij5Mb2Es PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48YnI+ DQo8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPk5v LCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC48L3A+ DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxicj4NCjwv cD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+SmVvbmct ZG9uZzwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ PGJyPg0KPC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4 Ij5QLlMuIEkgYW0gc2VuZGluZyB0aGlzIGVtYWlsIGFnYWluIGFzIHRoZSBwcmV2aW91cyBlbWFp bCB3YXMgZGVsaXZlcmVkIHRvIGEgbGltaXRlZCBzZXQgb2YgcmVjaXBpZW50cy4mbmJzcDs8L3A+ DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNeSBhcHBvbG9naWVzJm5ic3A7aWYgeW91IHJl Y2VpdmVkIHR3aWNlLjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lO LVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnQiPg0KPHAgc3R5bGU9 Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Ik9SR01BSUxfQ09OVEVOVCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxkaXY+PGI+ 67O064K4IOyCrOuejCA6IDwvYj4mcXVvdDtMb2EgQW5kZXJzc29uJnF1b3Q7ICZsdDtsb2FAcGku bnUmZ3Q7PC9kaXY+DQo8ZGl2PjxiPuuztOuCuCDrgqDsp5wgOiA8L2I+MjAxNi0xMS0wNyAxNDoy NjowNyAoICYjNDM7MDk6MDAgKTwvZGl2Pg0KPGRpdj48Yj7rsJvripQg7IKs656MIDogPC9iPm1w bHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCBkcmFmdC1pZXRmLW1wbHMtdHAtYXBz LXVwZGF0ZXNAaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtbXBscy10cC1hcHMtdXBkYXRlc0BpZXRm Lm9yZyZndDs8L2Rpdj4NCjxkaXY+PGI+7LC47KGwIDogPC9iPm1wbHMtY2hhaXJzQGlldGYub3Jn ICZsdDttcGxzLWNoYWlyc0BpZXRmLm9yZyZndDssIERlYm9yYWggQSBCcnVuZ2FyZCAmbHQ7ZGIz NTQ2QGF0dC5jb20mZ3Q7PC9kaXY+DQo8ZGl2PjxiPuygnOuqqSA6IDwvYj5JUFIgcG9sbCBvbiBk cmFmdC1pZXRmLW1wbHMtdHAtYXBzLXVwZGF0ZXM8L2Rpdj4NCjxwIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KV29ya2luZyBHcm91cCwNCjxw IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0K PHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+ DQpXZSBhcmUgY3VycmVudGx5IHByZXBhcmluZyBkcmFmdC1pZXRmLW1wbHMtdHAtYXBzLXVwZGF0 ZXMtMDEgZm9yIHdvcmtpbmcNCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+Jm5ic3A7PC9wPg0KZ3JvdXAgbGFzdCBjYWxsLiBXZSB3aWxsIGRvIGFuIElQUiBw b2xsIHByaW9yIHRvIHRoZSB3Z2xjLg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBN QVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRoaXMgaXMgdG8gc3RhcnQgdGhlIElQUiBQb2xs Lg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8 L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNw OzwvcD4NCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0 Zi1tcGxzLXRwLWFwcy11cGRhdGVzPw0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBN QVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNj bG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQo8cCBzdHlsZT0iTUFSR0lO LUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCihzZWUgUkZDcyAzOTc5 LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KPHAgc3R5bGU9Ik1BUkdJ Ti1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NClRoZXJlIGlzIG5v IElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWluc3QgdGhpcyBkb2N1bWVudHMuDQo8 cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4N CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9w Pg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3Ig cGxlYXNlIHJlc3BvbmQgdG8NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+Jm5ic3A7PC9wPg0KdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Ig bm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRP TTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCklQUi4gKlRoZSByZXNwb25zZSBu ZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdC4qIFRoZQ0KPHAgc3R5 bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2Ug aGFzIGJlZW4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+ Jm5ic3A7PC9wPg0KcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo8 cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4N CjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9w Pg0KSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3Rl ZCBhcyBhbiBhdXRob3Igb3INCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+Jm5ic3A7PC9wPg0KY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkg cmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55DQo8cCBzdHlsZT0iTUFSR0lOLUJP VFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCklQUiB0aGF0IGhhcyBub3Qg eWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCjxwIHN0 eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAg c3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQov TG9hDQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNw OzwvcD4NCm1wbHMgd2cgY28tY2hhaXINCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1B UkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsg TUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpQUw0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006 IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpJJ3ZlIHJlc2VudCB0aGlzIG1haWws IGFwb2xvZ2llcyB0byB0aG9zZSBvZiB5b3UgdGhhdCBnb3QgaXQgdHdpY2UuDQo8cCBzdHlsZT0i TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjxwIHN0eWxl PSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0KLS0NCjxw IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+Jm5ic3A7PC9wPg0K PHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+ DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwv cD4NCkxvYSBBbmRlcnNzb24gZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPHAgc3R5bGU9 Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQpTZW5pb3Ig TVBMUyBFeHBlcnQgbG9hQHBpLm51DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH SU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQp IHBob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NA0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBw eDsgTUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A29236252SMTP2etriinfo_-- From nobody Mon Nov 7 00:50:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6E5129B5F; Mon, 7 Nov 2016 00:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR6VJYtN9piI; Mon, 7 Nov 2016 00:50:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A9F129AE5; Mon, 7 Nov 2016 00:50:12 -0800 (PST) X-AuditID: c1b4fb2d-5b107980000009f7-b2-58204043af1a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id CF.FD.02551.34040285; Mon, 7 Nov 2016 09:50:11 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 7 Nov 2016 09:50:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=acQDa0rulKGmDn8jmRUlnCDty7cHBc1wmrd/BEnSbbI=; b=GSWW5c4WYVpLXFXhWlCTLC1pMRnL7YCnbCR9LZqaCaiWewubgG4jsV4kD6k3bhYd8J5W8/8T3WpBL7So1MAHMU6PVpvX+HA51CBR/sHXUspWSqVmYvcfVy+Qi2SURG2MnD3Wyta32flJXXmfYNjue5jKh70pKkVGEt1NhmCrOkY= Received: from AM4PR07MB1521.eurprd07.prod.outlook.com (10.165.248.149) by AM4PR07MB1524.eurprd07.prod.outlook.com (10.165.248.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Mon, 7 Nov 2016 08:50:08 +0000 Received: from AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) by AM4PR07MB1521.eurprd07.prod.outlook.com ([10.165.248.149]) with mapi id 15.01.0707.004; Mon, 7 Nov 2016 08:50:08 +0000 From: Francesco Lazzeri To: Igor Bryskin , Dieter Beller Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Thread-Index: AQHSNscTVO3gaGLLzUa73Uh58WTwgKDNN3tA Date: Mon, 7 Nov 2016 08:50:07 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F1E1@dfweml501-mbx> <9762bdb8-e73c-7653-3243-f7add7a9ce7c@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F242@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesco.lazzeri@ericsson.com; x-originating-ip: [151.0.200.100] x-ms-office365-filtering-correlation-id: 3a4497e9-9bc4-4398-07f5-08d406eb13a5 x-microsoft-exchange-diagnostics: 1; AM4PR07MB1524; 7:meKShh6iWzAayyWi0vRAc8Ui2hhxIzbgwIVONpRPiWMevw5RuJrDIECc5u7i9dU1iRRcFfJ7vk4glr/OHlx56BO8tmnvaR7H3s/TF7o/OU/Gv0XAzZf+e0up/PRXTkEP9dpysODVwHDsRhvtJLIoqG+4dKmnpzeiK2MpuNBx8AHYziLOp0aDRpR5M54OdrlKMsm/P3KfyCFM3O/Ic6f11PWVuN8uW9Aq03xHqjLF9PSRrPkB3LFqL3BdOl/b9wf57SO+J4YJGpWR2qv2m1mYnO9cxPZep5g239OftoyCATdlpc7zPm5mO3PsKI5Mm+pCdVEXzEcmd5KB7IiHOANu+yuUhUJQi5Zebi4qp482K2A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(50582790962513)(82608151540597)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM4PR07MB1524; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1524; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(377454003)(189002)(24454002)(199003)(7736002)(7906003)(74316002)(92566002)(7846002)(106356001)(15975445007)(101416001)(106116001)(5660300001)(790700001)(77096005)(189998001)(2906002)(81166006)(19300405004)(2950100002)(19580395003)(8676002)(81156014)(102836003)(7696004)(6116002)(2900100001)(68736007)(3846002)(9686002)(8936002)(5002640100001)(4326007)(586003)(10400500002)(33656002)(87936001)(76176999)(76576001)(19580405001)(220493001)(86362001)(122556002)(11100500001)(3900700001)(5001770100001)(230783001)(16236675004)(66066001)(105586002)(3280700002)(93886004)(3660700001)(54356999)(50986999)(19617315012)(97736004)(19625215002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB1524; H:AM4PR07MB1521.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 08:50:08.0414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1524 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUURTHue+9mXmaE9dR86BSOiSYoaVGPTHCFsMPSdKmSC5DPtxHnWeS UeCSQ5mlUy45KhmMhfuKCUroaJZCZmEq41qaWhqJhGtKzjwlv/3u+f/uPfdcLk1K3gus6Ah5 AquQy6KlQmOqwP/1Gaeznrb+Rx+vWTBTRUMUU60ZoZiNbhdm9ZMjoystEzCp40MiJn2lmfIU ed/r/CXw1mhWCe9R3WfClwwwPhnKRkcksoojp0KMw1OWa4Vxda3kLfWslkhGK/fJDGREAz4G TSqlKAMZ0xJcjeDP0k9DIMHvEJRXB+oDCj8iQZVeTPBWHgElyrT/1qgO6VmIGVjrLKT0bI6v Qk1tEdJvIPEgguKnI4IMRNNm+Dr0Kk15JxByJxoofdkcu8JoVoi+TOGD0NZbbDhGvGXnDy8K +b4LIkhXzRj6GmEvKJ8pNPRFeB8s91QSeiaxJeimnhP8aBg0rR+3x7SAH5ObAt6XQZ1Gve3Y QV/5DvvAsCZVoG8GuISE370d28F5aP8yK+I5Cmb7NgheykDw5msmxS+aESxO9gt5ywbmSqa2 rS4hVCg1iH8vFl5VpRvYDFvBaP8DlI0OqXddnedYyF9OJdWGNzCF7oIpiq87w1BujpDnw/Dy xRzJsxM829RSu+slSFSOLDiW42LCXN2cWUXEDY6LlTvL2YR6tPW/2hvXnZpRxdxpLcI0kpqI 47wO+EsEskQuKUaLgCal5mIPD1t/iThUlnSbVcQGK25Gs5wWWdOU1FJ8vGzcT4LDZAlsFMvG sYqdlKCNrJJR5EC1bVCiiaqqkXnY6ffNM6hB1RS0pymvZ7BFnVKV5Us/WZSesL6T7aZczyt2 KrrgILrsQS5MKzeCakzquyoVl9Lu5gQ3fo+fCEiYj4zM6RqLaplO+Su8eCW1Jm26a/85+1If G69498xr+Tpir8OSvCrPfX62jeoYeGtnP/ZhyU1KceEyF0dSwcn+ASST6thbAwAA Archived-At: Cc: "mpls@ietf.org" , "CCAMP \(ccamp@ietf.org\)" , "Scharf, Michael \(Nokia - DE\)" , "pce@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 08:50:18 -0000 --_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The point here is for how long the provider should keep the computed path a= nd its request parameters (in fact if we want to have a possibly better pat= h, at any change inside provider topology, resource status and usage, the p= rovider should check if the computed path is still feasible and/or redo pat= h computation to find a better path). This could be an overhead, in my view= . Furthermore, I can't see how the provider could export the abstract TE-link= , as this is inside the client topology; in fact, if the client is asking f= or a path between A and B (A and B inside provider topology), having A' (in= client topology) connected to A and B' (in client topology) connected to B= , the relevant abstract TE link (the forwarding adjacency) should be built = between A' and B', that is in the client topology; therefore the client sho= uld be in charge of managing it, as the provider is not aware of A' and B'. BR Francesco From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: 04 November, 2016 7:12 PM To: Dieter Beller Cc: mpls@ietf.org; CCAMP (ccamp@ietf.org) ; Scharf, Michael= (Nokia - DE) ; TEAS WG (teas@ietf.org) ; pce@ietf.org Subject: Re: [CCAMP] [mpls] http://tools.ietf.org/html/draft-busibel-teas-y= ang-path-computation-00 Dieter, A client may ask for a path not to be used immediately (e.g. to present as = an abstract TE link to its own client, in some failure restoration scheme o= r as a part of disaster recovery network topology re-configuration) without= committing any network resources. In this case the client would want to kn= ow at least if/when the path has stopped being feasible any longer or (ide= ally) a better path is available. This is similar to exposing to a client an abstract TE topology with an unc= ommitted abstract TE link (i.e. TE link that does not have a committed TE t= unnel supporting it and advertises potentiality). Once such link is provide= d, the provider is expected to send updates when/if the TE link attributes = change. For uncommitted/potential TE link such updates could be provided ba= sed on event driven re-computation of the potentiality the TE link represen= ts. The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunne= l can represent (each in its own way) the same network potentiality Cheers, Igor From: Dieter Beller [mailto:Dieter.Beller@nokia.com] Sent: Friday, November 04, 2016 1:49 PM To: Igor Bryskin Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi Igor, could you please clarify how useful a stateful path without resource alloca= tion is. I can't see the benefits of this use case. Thanks, Dieter On 04.11.2016 14:25, Igor Bryskin wrote: Hi Dieter, A provider may compute path(s) for a TE tunnel, and then (without any resou= rce allocation) may start monitoring/ensuring the path validity/optimality = by re-computing them in an event driven manner. For example, it can trigger= the re-computation of the path(s) when detecting a change in a state of a = TE link the current path(s) are going through. Depending on the results ad= ditional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for i= mplementing stateful path computation (such as compute_and_reserve). Cheers, Igor From: Beller, Dieter (Nokia - DE) [mailto:dieter.beller@nokia.com] Sent: Thursday, November 03, 2016 6:27 PM To: Leeyoung Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path= -computation-00 Hi all, when we talk about the stateful path computation use case, it means IMHO th= at when a path has been calculated successfully in response to a request, a= new path object is created in the data store. This does only make sense if= the resources have been allocated in the TED of the PCE irrespective of th= e fact whether the connection along this path will be established right awa= y or at a later point in time. This will prevent further path computation r= equests from assuming that the resources are still available. As the TED of= the PCE also has to reflect the network state, I would assume that the net= work resources can be in one of the following three states: available, allo= catedButNotInUse, allocatedAndInUse. The path objects also need state info= rmation reflecting for example the alarm state of the allocated resources. = The path calculated earlier may become (temporarily) invalid due to a link = failure affecting the path. Does this make sense? Thanks, Dieter Sent from my tablet Leeyoung wrote: Igor, When you say "state", are you referring to the YANG datastore or some other= "interim" state of those paths that are calculated but not instantiated as= LSPs? If we were to update the YANG datastore for this, I would think that= we may have some issue when the customer decided not to instantiate the TE= tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will hav= e exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, the= n the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; Daniele Ceccarelli; CCAMP (ccam= p@ietf.org); pce@ietf.org; TEAS= WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to cr= eate/maintain the normal TE tunnel state and (re-)compute TE paths for the = TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Isn't the intention of defining "compute-only tunnels" to create state in t= he controller, but not to signal them? If the tunnel should be signaled and= resources shall be allocated, why not just configure a vanilla tunnel? Use= s cases seem to exist for both variants, and both can be encoded in YANG. I= s there anything I miss here? Michael From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Thursday, November 03, 2016 7:49 PM To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin; CCAMP (= ccamp@ietf.org); pce@ietf.org; = TEAS WG (teas@ietf.org); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Hi Michael, I think I am with you on your point. If we use rpc, it is clear. On the oth= er hand, if we were to use "stateful compute-only" it seems that the system= /controller has to keep the state of the paths somewhere which is not YANG = datastore. My understanding is that YANG datastore is updated only when the= path is signaled and resource is allocated. Would this give the system/con= troller additional burden to keep the "interim" state? Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia - DE) Sent: Thursday, November 03, 2016 8:58 AM To: Daniele Ceccarelli; Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.org); mpls@ietf.org Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Maybe I miss something, but to me, the domain controller either computes a = path stateless, which can be modeled in YANG in an RPC. Or the domain contr= oller computes a path, stores state, and provides access to the result in t= he YANG datastore. In the latter case, whether resources are allocated, or = whether the NEs get actually provisioned, is an orthogonal question. As a side note, I am not sure of I would call a domain controller or an NMS= a PCE. Path computation is only a subset of the functions of a domain cont= roller. Michael From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, November 03, 2016 2:49 PM To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org); pce@ietf.org; TEAS WG (teas@ietf.o= rg); mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 Can you please explain what the "stateful compute-only" stands for I don't = understand what is stateful in a path computation request only. IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path= and then forget about it or I ask to compute and provision it. I don't und= erstand the value of asking for it and remembering about it. BR Daniele From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: gioved=EC 3 novembre 2016 14:45 To: Igor Bryskin >;= Daniele Ceccarelli >; CCAMP (ccamp@ietf.org) >; pce@ietf.org; TEAS WG = (teas@ietf.org) >= ; mpls@ietf.org Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-comput= ation-00 We have discussed this before. From an implementer's perspective, the two c= lean solutions to the problem seem to either stateful "compute-only" tunnel= s or a stateless RPC. Michael From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org); pce@= ietf.org; TEAS WG (teas@ietf.org= ); mpls@ietf.org Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-pat= h-computation-00 Hi, >From the draft: 6. YANG Model for requesting Path Computation Work on extending the TE Tunnel YANG model to support the need to request path computation has recently started also in the context of the [TE-TUNNEL] draft. It is possible to request path computation by configuring a "compute-only" TE tunnel and retrieving the computed path(s) in the LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. This is a stateful solution since the state of each created "compute-only" TE tunnel needs to be maintained and updated, when underlying network conditions change. The need also for a stateless solution, based on an RPC, has been recognized. The YANG model to support stateless RPC is for further study. IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_= FORGET mode. We also consider the concept of path computation action to be = defined under the TE tunnel node. All this is to facilitate stateless path = computations. Cheers, Igor --_000_AM4PR07MB1521420400F50B015E91AA5796A70AM4PR07MB1521eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable