Re: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco Lazzeri <francesco.lazzeri@ericsson.com> Fri, 04 November 2016 10:17 UTC

Return-Path: <francesco.lazzeri@ericsson.com>
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 <francesco.lazzeri@ericsson.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>, Leeyoung <leeyoung@huawei.com>, "Beller, Dieter (Nokia - DE)" <dieter.beller@nokia.com>
Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Thread-Index: AQHSNdctiq61/EtmPkOM+rTQF01xh6DHupQAgAABPQCAAAJUAP//2oaAgAAJPQCAAATDAIAAAkeAgAAFvQCAAALEAIAAJckAgAAGhwCAAGBnAIAAWvUQ
Date: Fri, 04 Nov 2016 10:07:19 +0000
Message-ID: <AM4PR07MB152109CAC2B9B02FA7ADBF6E96A20@AM4PR07MB1521.eurprd07.prod.outlook.com>
References: <AM2PR07MB09943987D6E27931F8C7CF3EF0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <AM2PR07MB0994C0B4EB099666B97844C0F0A30@AM2PR07MB0994.eurprd07.prod.outlook.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> <slkuudfq6hfpvsvrdv85tj8f.1478211220486@email.android.com> <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: <AM4PR07MB15236E1096FFA21AF201220D96A20@AM4PR07MB1523.eurprd07.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/mpls/-WeIHcwdW13M-Ua06QnfirUWgyA>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>, "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "pce@ietf.org" <pce@ietf.org>, "TEAS WG (teas@ietf.org)" <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 <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2016 10:17:54 -0000

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 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 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] 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>; Scharf, 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 implement a simple path computation request, the rpc is the way to go.
Doing this via tunnel creation would require 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 Stateful compute-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<mailto:dieter.beller@nokia.com>>
Cc: Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>; pce@ietf.org<mailto: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 that. However, 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 requests turn into instantiation of tunnels (the paths are signaled and resource 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 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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto: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 that 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 the fact whether the connection along 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 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 (temporarily) invalid due to a link failure affecting the path.



Does this make sense?





Thanks,

Dieter



Sent from my tablet



Leeyoung <leeyoung@huawei.com<mailto:leeyoung@huawei.com>> 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 (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Young,

>From the provider controller point of view COMPUTE_ONLY TE tunnels will have 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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

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; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto: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/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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Isn't the intention of defining "compute-only tunnels" 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?

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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
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/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/controller additional burden to keep the "interim" state?

Young

From: CCAMP [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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-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 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 controller.

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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto: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 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 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ì 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>; mpls@ietf.org<mailto: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 to 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<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-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
   request path computation has recently started also in the context of
   the [TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-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<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-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