Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Francesco Lazzeri <francesco.lazzeri@ericsson.com> Mon, 07 November 2016 08:50 UTC
Return-Path: <francesco.lazzeri@ericsson.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 <francesco.lazzeri@ericsson.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, Dieter Beller <Dieter.Beller@nokia.com>
Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Thread-Index: AQHSNscTVO3gaGLLzUa73Uh58WTwgKDNN3tA
Date: Mon, 07 Nov 2016 08:50:07 +0000
Message-ID: <AM4PR07MB1521420400F50B015E91AA5796A70@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> <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: <AM4PR07MB1524BEF44DBAC5D22B22C6AA96A70@AM4PR07MB1524.eurprd07.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/pce/1IylaWyb-FVWHvG02qdjuvb-EDs>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Subject: Re: [Pce] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2016 08:50:18 -0000
The point here is for how long the provider should keep the computed path and its request parameters (in fact if we want to have a possibly better path, at any change inside provider topology, resource status and usage, the provider should check if the computed path is still feasible and/or redo path 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 for 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 should 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 <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 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 disaster recovery network topology re-configuration) without committing any network resources. 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 available. This is similar to exposing to a client an abstract TE topology with an uncommitted abstract TE link (i.e. TE link that does not have a committed TE tunnel supporting it and 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 could be provided based on event driven re-computation of the potentiality the TE link represents. The point is that an uncommitted 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; 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 Igor, could you please clarify how useful a stateful path without resource allocation 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 resource 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 additional notifications may be sent to the client. Note that this is in addition to the reasons you correctly identified for implementing 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<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
- [Pce] CCAMP and JOINT YANG session agenda @IETF97 Daniele Ceccarelli
- [Pce] draft-zhang-ccamp-transport-yang-gap-analys… Igor Bryskin
- [Pce] http://tools.ietf.org/html/draft-busibel-te… Igor Bryskin
- Re: [Pce] [Teas] draft-zhang-ccamp-transport-yang… Belotti, Sergio (Nokia - IT)
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Scharf, Michael (Nokia - DE)
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Daniele Ceccarelli
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Scharf, Michael (Nokia - DE)
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Igor Bryskin
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Daniele Ceccarelli
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Belotti, Sergio (Nokia - IT)
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Igor Bryskin
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Igor Bryskin
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Daniele Ceccarelli
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Leeyoung
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Scharf, Michael (Nokia - DE)
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Igor Bryskin
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Leeyoung
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Igor Bryskin
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Leeyoung
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Beller, Dieter (Nokia - DE)
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Leeyoung
- Re: [Pce] [Teas] draft-zhang-ccamp-transport-yang… Zhangxian (Xian)
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Dhruv Dhody
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] http://tools.ietf.org/html/draft-busibe… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Dieter Beller
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- [Pce] 答复: [mpls] http://tools.ietf.org/html/draft… Fatai Zhang
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- [Pce] 答复: [mpls] http://tools.ietf.org/html/draft… Fatai Zhang
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Belotti, Sergio (Nokia - IT)
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [Teas] [mpls] http://tools.ietf.org/htm… Italo Busi
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [Teas] [mpls] http://tools.ietf.org/htm… Igor Bryskin
- Re: [Pce] [Teas] [mpls] http://tools.ietf.org/htm… Italo Busi
- Re: [Pce] [Teas] [mpls] http://tools.ietf.org/htm… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [Teas] [mpls] http://tools.ietf.org/htm… Italo Busi
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Igor Bryskin
- Re: [Pce] [mpls] http://tools.ietf.org/html/draft… Francesco Lazzeri
- Re: [Pce] [Teas] [mpls] http://tools.ietf.org/htm… Igor Bryskin