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

Fatai Zhang <zhangfatai@huawei.com> Thu, 10 November 2016 06:13 UTC

Return-Path: <zhangfatai@huawei.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 9F98912948F; Wed, 9 Nov 2016 22:13:29 -0800 (PST)
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 jhIW7yJ716MF; Wed, 9 Nov 2016 22:13:24 -0800 (PST)
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 F381C129476; Wed, 9 Nov 2016 22:13:22 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUW61667; Thu, 10 Nov 2016 06:13:19 +0000 (GMT)
Received: from SZXEMA419-HUB.china.huawei.com (10.82.72.37) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Nov 2016 06:13:18 +0000
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.10]) by SZXEMA419-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0235.001; Thu, 10 Nov 2016 14:13:06 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, Francesco Lazzeri <francesco.lazzeri@ericsson.com>, Dieter Beller <Dieter.Beller@nokia.com>
Thread-Topic: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Thread-Index: AQHSNdcrsnImRWIBx06pjw3t0cGI9KDGvx8AgAABPQCAAAJUAIAAUW6AgAAHrgCAAATCAIAAAkeAgAAFvgCAAALEAIAAJckAgAD66ACAAEl9gIAABo6AgAQaA4CAA7+XAP//uG+AgAAKYICAAAX9gIAACzMAgAAIJACAAUXkoA==
Date: Thu, 10 Nov 2016 06:13:06 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF8817AC634@SZXEMA504-MBS.china.huawei.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> <AM4PR07MB1521420400F50B015E91AA5796A70@AM4PR07MB1521.eurprd07.prod.outlook.com> <F82A4B6D50F9464B8EBA55651F541CF8817AC188@SZXEMA504-MBS.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F747@dfweml501-mbx> <AM4PR07MB1521754E4B30DF2F386DFB7196B90@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F774@dfweml501-mbx> <AM4PR07MB15214CB0075CBB583A96B82B96B90@AM4PR07MB1521.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0F7CA@dfweml501-mbx>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.162.94]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8817AC634SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58241000.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.10, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f25b10f72311b09d545105e131638d3a
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Tex_kT1CkRgCrfzLsvpfXi3DDrY>
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: [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: Thu, 10 Nov 2016 06:13:29 -0000

Hi Igor,

I think the client will still meet the case that there is no available path for the client.

The provider will have no chance to re-plan the path when the client knows the unfeasibility ahead of short time (e.g., milliseconds before it really needs the path) or the client knows the unfeasibility ahead of much time (e.g., hours or days) before it really needs, but there is no sufficient available resource for the provider to re-plan unless the operators add more physical nodes or links.

I think the stateful path computation is a kind of “best effort”, and it might be suitable for IP service, but for the transport service, the protection capability(as you mentioned a failure recovery or congestion avoidance strategy or disaster topology re-configuration) MUST be guaranteed (at least for one single failure) if the client really relies on that.

I think the simple way to guarantee the protection (or whatever) capability is to reserve the resource for the desired path and the reserved resource could be shared among multiple path (This is the concept of Shared Mesh Protection I introduced in ITU-T SG15 a few years ago, but here we can just reserve the resource from the control plane perspective rather than reserve the resource on the data plane through SMP mechanism).



Thanks

Fatai

发件人: Igor Bryskin
发送时间: 2016年11月9日 23:56
收件人: Francesco Lazzeri; Fatai Zhang; Dieter Beller
抄送: mpls@ietf.org; CCAMP (ccamp@ietf.org); Scharf, Michael (Nokia - DE); pce@ietf.org; TEAS WG (teas@ietf.org)
主题: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco,

Please, see in-line.

Igor



From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); Scharf, Michael (Nokia - DE); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
Subject: Re: [Teas] [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,


1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: “ No, I have nothing for you” ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?
       FL>> Probably the same in case the provider notifies “Hey, I have no longer anything for you”.

IB>> But this would be a bit too late, wouldn’t it? Wouldn’t it be better if the client has learnt about the previously returned path unfeasibility ahead of time, so that it could re-plan it’s failure recovery scheme?

If there is no (more) path, there is no path. The client could only try and crankback looking for some different path or report an alarm.

IB>> Relying on crankbaks in an unpredictable way is not exactly a good solution, right?

The scenario that seems more applicable to your proposal is a pre-planned restoration mechanism where we have a worker path in-service and a protection path just computed (but not reserving network resources, in order to share them among several protection paths), in a multi-domain network. In that case, reserving te-tunnels like you suggest, could give an advantage, as the end-to-end cranckback could occur when the notification with “no-path” is triggered by the provider (that means the protection path or some of its segments is no longer valid) and not when the path deployment is triggered by the client (that means the worker path is gone and we need the protection immediately). Is this the case you are considering ?

IB>> Exactly. All the scenarios you can think of where you don’t know when and where a problem may happen and you want to maintain flexibility and share the network resources to protect as much as you can

In other cases, as when used during an end-to-end path computation with immediate deployment to reduce the possibility of conflicts among concurrent procedures, it seems to me less important or applicable, as all these procedures will likely be orchestrated by the same entity, which could well avoid conflicts.

IB>> All cases where the provider wants to expose a potentiality without committing resources to cover for the client multiple use cases and provide at the same time some degree (albeit not perfect) predictability.




2)      Regarding the abstract link in the overlay topology, I still can’t see what the provider will advertise. If it’s a new link representing the forwarding adjacency between A’ and B’, how it will be represented by the provider ?

IB>> According to the TE topology model abstract TE link A’B’ points to the underlay (provider) TE topology where the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. link advertising potentiality in the provider network). In either case TE link’s attributes (e.g. available bandwidth, SRLGs) are defined by the path.
FL>> This means that the provider just sends the reply to the path computation request and doesn’t advertise any new TE link to the client ? This is actually what I would expect: the task to manage TE-links in the overlay topology is with the client.

IB>> Overlay TE topology manager advertises a TE link that is supported not by a provisioned in a server layer TE tunnel (connection), rather, by a computed and monitored path. This way the overlay TE topology manger can advertise multiple abstract TE links mapped onto the same network resources

Francesco


From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 3:47 PM
To: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: 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>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco,


1)      IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: “ No, I have nothing for you” ?  What if the path was relied upon by the client for a failure recovery or congestion avoidance strategy or disaster topology re-configuration?





2)      Regarding the abstract link in the overlay topology, I still can’t see what the provider will advertise. If it’s a new link representing the forwarding adjacency between A’ and B’, how it will be represented by the provider ?

IB>> According to the TE topology model abstract TE link A’B’ points to the underlay (provider) TE topology where the path is computed and provisioned as supporting TE tunnel for committed TE link or not provisioned (but monitored) for uncommitted TE link (i.e. link advertising potentiality in the provider network). In either case TE link’s attributes (e.g. available bandwidth, SRLGs) are defined by the path.


Igor


From: Francesco Lazzeri [mailto:francesco.lazzeri@ericsson.com]
Sent: Wednesday, November 09, 2016 9:26 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); Scharf, Michael (Nokia - DE); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>)
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,
IMHO simplicity pays back. Instead than maintaining all these states, notifying clients all the times something changes, and repeating path-computation as needed, isn’t better for a client (and provider) to ask what is needed when it’s needed, and get the best result back at that moment ?
Regarding the abstract link in the overlay topology, I still can’t see what the provider will advertise. If it’s a new link representing the forwarding adjacency between A’ and B’, how it will be represented by the provider ?

BR
Francesco

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: 09 November, 2016 2:48 PM
To: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>; Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Dieter Beller <Dieter.Beller@nokia.com<mailto:Dieter.Beller@nokia.com>>
Cc: 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>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>
Subject: RE: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Francesco,

Please, see in-line.

Cheers,
Igor

The point here is for how long the provider should keep the computed path and its request parameters

IB>> As far as the provider is concerned, the requested path and its parameters is a TE tunnel (albeit computed but not provisioned). So it keeps the state until the client removes the TE tunnel.

(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.

IB>> For example, if provider is to ensure the path’s feasibility, all it needs is to detect a change in a TE link the path is going through and make sure that the  change does not make the path unfeasible. Only in the latter case the path re-computation needs to be scheduled and performed in a background thread.

Furthermore, I can’t see how the provider could export the abstract TE-link, as this is inside the client topology;
IB>> The abstract link is a part of the abstract topology “cooked” (customized) for the client, which is supported by the computed path in the underlay topology, which is the provider’s 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’.

IB>> This is correct, but note that the two topologies (underlay and overlay) according to the TE topology model have independent and unrelated name spaces for node, link and SRLG IDs. So it is perfectly Ok.

IB>> Also note that according  to TE topology model  one important attribute of a TE node (especially abstract composite node) is connectivity matrix, which is nothing but a set of stateful paths computed, re-computed and constantly monitored (but not reserved) over the TE topology the node encapsulates.  This means that stateful unreserved paths play already a very important part in supporting TE topologies with asymmetrical blocking abstract TE nodes.

Igor




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<mailto:Dieter.Beller@nokia.com>>
Cc: 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: [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