Re: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Italo Busi <Italo.Busi@huawei.com> Fri, 23 November 2018 16:22 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1D7130E30 for <teas@ietfa.amsl.com>; Fri, 23 Nov 2018 08:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1QFRKLodHT8X for <teas@ietfa.amsl.com>; Fri, 23 Nov 2018 08:22:13 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E20051241F6 for <teas@ietf.org>; Fri, 23 Nov 2018 08:22:12 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E46B137C116AC; Fri, 23 Nov 2018 16:22:07 +0000 (GMT)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml704-cah.china.huawei.com ([10.201.108.45]) with mapi id 14.03.0415.000; Fri, 23 Nov 2018 16:22:03 +0000
From: Italo Busi <Italo.Busi@huawei.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "sergio.belotti@nokia.com" <sergio.belotti@nokia.com>, Dhruv Dhody <dhruv.dhody@huawei.com>
CC: "francesco.lazzeri@ericsson.com" <francesco.lazzeri@ericsson.com>, "carlo.perocchio@ericsson.com" <carlo.perocchio@ericsson.com>, "dieter.beller@nokia.com" <dieter.beller@nokia.com>, "daniele.ceccarelli@ericsson.com" <daniele.ceccarelli@ericsson.com>, "dhruv.ietf@gmail.com" <dhruv.ietf@gmail.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation
Thread-Index: AdSDQhejek3ppqt3T4WYwZKlE5jb1wAAa85Q
Date: Fri, 23 Nov 2018 16:22:02 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B276599D9@lhreml504-mbs>
References: <etPan.5bf81e75.116bf489.fea@localhost>
In-Reply-To: <etPan.5bf81e75.116bf489.fea@localhost>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.236]
Content-Type: multipart/alternative; boundary="_000_91E3A1BD737FDF4FA14118387FF6766B276599D9lhreml504mbs_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/8uPqoGtk7mbI4X5U2t3rqZZV8ps>
Subject: Re: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Nov 2018 16:22:18 -0000

Hi Igor,

As you have mentioned at the beginning, we are reducing the possibility for the returned path to become unavailable, but not making it zero

As a consequence, the client still needs to implement a logic to deal with the situation when this undesired situation happens (either because of an unlikely event or because the controller was not smart enough). Before IETF 103, we have updated the text in section 3.3 of the draft to indicate that the client should always check that the path being setup is ok

I think that the “sticky” approach proposed by you and Dhruv provides a clear enhancement but I also share Sergio’s viewpoint about the need to evaluate whether all these enhancements are worth the effort/complexity. In other words, the idea is valid but it is not clear whether its value is worth the effort

What do you think?

Please note that it is possible to share the resources allocated to multiple candidate paths for the same request only on the common links. Therefore, when this “sticky” approach is used, there will be some resources allocated within the network that are not going to be released without being used for the path they have been reserved for

Thanks, Italo

From: Igor Bryskin
Sent: Friday, November 23, 2018 4:35 PM
To: sergio.belotti@nokia.com; Dhruv Dhody <dhruv.dhody@huawei.com>;
Cc: francesco.lazzeri@ericsson.com; carlo.perocchio@ericsson.com; Italo Busi <Italo.Busi@huawei.com>;; dieter.beller@nokia.com; daniele.ceccarelli@ericsson.com; dhruv.ietf@gmail.com; Igor Bryskin <Igor.Bryskin@huawei.com>;; teas@ietf.org
Subject: Re: RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Sergio,

Please, see my comments in line.
Igor
From:Belotti, Sergio (Nokia - IT/Vimercate)
To:Dhruv Dhody,
Cc:francesco.lazzeri@ericsson.com,carlo.perocchio@ericsson.com,Italo Busi,Beller, Dieter (Nokia - DE/Stuttgart),Daniele Ceccarelli,'Dhruv Dhody',Igor Bryskin,teas@ietf.org,
Date:2018-11-23 04:09:54
Subject:RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Dhruv,
Happy to hear you agree on the approach.

About the “stickiness” of resources , I have (and other co-authors/contributors with me) a couple of comments.
First point is that our  path computation stateless  is computing a set of “candidates” paths , out of them only one will be selected . In one domain this means that you could have a reasonable number of candidates paths and theoretically, following the sticky approach, you should reserve resources for all candidates. This could be very challenging , you should assume that the domain would have resources for all , and this is in general not true.
It is obvious that this would not be a problem in case of single path, that is not our case.

IB》Precisely because only one path cadidate will be eventually selected, the whole set of path candidates may share the "sticky" resources between each other, but not with other path candidate sets (produced by separate path computations). So your concern is understandable, but presents no problem. Generally speaking,  the server may be as creative as it likes to be  in projecting the computed stateful paths on TE topology. This is an implementation ( but should  not  be modeling) problem. In other words, it is reasonable  to assume that some servers will be "smarter" than others, and the model should not limit the server capabilities artificially and unnecessarily.



The second point that make me doubtful, is that we are discussing solutions to cope with real corner case: I pretty convinced that in 90% of the cases the “pure” stateless solution can be exhaustive , and for this reason I would avoid to create a “monster” to cover very limited set of scenarios.
So, I think the adoption of a “sticky” solution, would be worth considering with great attention, and specific  discussion (maybe a call) would be needed.

IB》Compared to the process of TE topology auto-discovery, projecting of already known/computed paths on the topology is nearly instantaneous and therefore cheap for the server. Note, that the client will still be able to rely on purely stateless computations, but if you assume that in 10% of the cases, the approach may fail, it means that the client  will have to implement logic for such cases (it cannot just ignore them, can it?), whichs seems to be quite expensive for the client.

Said that you suggestion to have an explicit request from client of type of path computation (pure-stateless, compute-only, compute-and-reserve) would be the better way to proceed, in case WG would like to do that.
IB》No problem with that. Note that if PCEP cannot do this today, it does not mean we should not try to do that either,

Thanks
Sergio


From: Dhruv Dhody <dhruv.dhody@huawei.com<mailto:dhruv.dhody@huawei.com>>
Sent: Thursday, November 22, 2018 1:25 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>; Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; teas@ietf.org<mailto:teas@ietf.org>
Cc: francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>; carlo.perocchio@ericsson.com<mailto:carlo.perocchio@ericsson.com>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; 'Dhruv Dhody' <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Subject: RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Italo, Sergio,

Apologies for a late response. I agree with your approach and these mechanism are all complimentary to each other and IMHO should be supported in your I-D. Looking forward to the next update.

Also it might be worth exploring if there should be a way to set the “stickiness” of resources for path computation request as an additional parameter. Along with storing of path, the resources could also be reserved “temporarily” based on it.

Thanks!
Dhruv


Dhruv Dhody
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066
Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dhody@huawei.com<mailto:dhruv.dhody@huawei.com>
[Huawei-small]
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:sergio.belotti@nokia.com]
Sent: 08 November 2018 12:40
To: Dhruv Dhody <dhruv.dhody@huawei.com<mailto:dhruv.dhody@huawei.com>>; Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; teas@ietf.org<mailto:teas@ietf.org>
Cc: francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>; carlo.perocchio@ericsson.com<mailto:carlo.perocchio@ericsson.com>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>
Subject: RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Dhruv, Igor,
Thanks for your feedbacks and discussion
So far, we have heard support from you to explore this possible enhancement and no opposition. It seems therefore worthwhile investigating some detailed technical issues on how this option can work.

About point 1) Dhruv’s understanding is correct.

Since this new approach is not completely stateless, there is the need for garbage collection.
One possible approach is to use a timeout that, when it expires, triggers the removal of the computed path from the state DS. This operation is fully controlled by the server (PNC) without the need for any action to be taken by the client (MDSC)

Another possible approach is to tag each path computation requests with a transaction-id and to define a new RPC that explicitly removes all the computed paths associated with a transaction-id and that exists only in the state DS.
This approach is useful when multiple paths  are computed but only one is setup (e.g., in case of multi-domain path computation): after the selected path is setup, all the other computed path can be deleted using a single RPC (which is still to be defined), without waiting for timers to expire.
We think this can address your point 2).

From our off line discussion we have understood that a third option is possible, which is to automatically remove all the computed paths remained in the state DS and associated with the same transaction id when one path with this transaction id has been successfully setup.

We think that this third option can be complementary to the second option since the delete RPC (we have mentioned above) may be needed to delete computed paths in transit domains which have not been selected for path setup.
We are also thinking that the timer approach is always needed to avoid stranded computed paths being stored in the state DS when no path is setup and no explicit delete RPC is received.
What do you think?
Would the timer approach be sufficient or do you prefer to define also the second and/or the third approach to optimize the removal of paths that have been computed and will never be setup?
Thanks
Italo and Sergio

From: Dhruv Dhody <dhruv.dhody@huawei.com<mailto:dhruv.dhody@huawei.com>>
Sent: Monday, November 5, 2018 4:27 AM
To: Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; teas@ietf.org<mailto:teas@ietf.org>
Cc: francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>; carlo.perocchio@ericsson.com<mailto:carlo.perocchio@ericsson.com>
Subject: RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Igor,

See inline..

From: Igor Bryskin
Sent: 01 November 2018 20:26
To: Dhruv Dhody <dhruv.dhody@huawei.com<mailto:dhruv.dhody@huawei.com>>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; teas@ietf.org<mailto:teas@ietf.org>
Cc: francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>; sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>; carlo.perocchio@ericsson.com<mailto:carlo.perocchio@ericsson.com>
Subject: Re: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Dtuv,

to your 1: compute-only tunnel is a tunnel and stays as long as it is configured. At the moment of actual provisioning it is either converted into "real" tunnel or destroyed,
[[[Dhruv Dhody]]] In the email below Italo said that the “…also creates a compute-only te-tunnel in the state DS” i.e. they would not be in the config and thus could not be deleted via config. As I was discussing this with Italo another rpc or a timer or both could be considered.

to yout 2: only selected path (s) will have status of compute-only tunnels.
[[[Dhruv Dhody]]] At T1, we may ask for multiple paths and T2 there is only one that is selected. So at T2 a clear way to free up other state is something that is needed.

Thanks!
Dhruv

Igor
From:Dhruv Dhody
To:Italo Busi,TEAS WG,
Cc:Francesco Lazzeri,Belotti, Sergio (Nokia - IT/Vimercate),Carlo Perocchio,
Date:2018-10-31 21:15:48
Subject:Re: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Italo,

Overall it make sense, but…


(1)  What are your thoughts on the state (compute-only) created at T1. And maybe the request (at T2) never comes? Would this live forever? Some mechanism to clear this would be nice!

(2)   Also let’s consider a case where MDSC asks a PNC to compute bunch of paths from various IN branch nodes to EXIT branch nodes (common in case of H-PCE like computations on transit domain) and based on the path computation at MDSC (or parent PCE) it determines that one of them needs to be setup. So in this cases should we stay away from this? Or is there a way to use this still!

I remember ages ago this was discussed in PCE WG as well (but that was before we had stateful PCE), maybe a good idea to think about it again!

Thanks!
Dhruv

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Italo Busi
Sent: 31 October 2018 21:50
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>
Cc: Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>; Carlo Perocchio <carlo.perocchio@ericsson.com<mailto:carlo.perocchio@ericsson.com>>
Subject: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation


Dear TEAS WG,



Following-up mailing list discussions after IETF 102, we would like to discuss the proposal for a possible enhancement to the path computation RPC defined in draft-ietf-teas-yang-path-computation-03



The stateless path computation solution  requires that the YANG DS server (e.g., a PNC)  computes a path twice before setting up an LSP: at time T1, when its client (e.g., an MDSC) sends a path computation RPC request, and later, at time T2, when the same client (MDSC) creates a te-tunnel requesting the setup of the LSP.



The underlying assumption is that, if network conditions have not changed, the same path that has been computed at time T1 is also computed at time T2, by the server (PNC) and therefore the path that is setup at time T2 is exactly the same path that has been computed at time T1



From the mailing list discussion after IETF 102, it seems that some people think that it is not necessary to guarantee that the path setup at time T2 is exactly the same as the path computed at time T1 but only that it has the same or better metrics, while other people would like to be able to setup at time T2 the path computed at time T1, if still available



One possibility to achieve the latter behavior is to use the stateful path computation solution described in section 3.3.1 of draft-ietf-teas-yang-te-17. However, this approach has some drawbacks as described in section 3.3 of draft-ietf-teas-yang-path-computation-03



We think that it is also possible to define some extensions to the path computation RPC where the server (PNC), after having received a path computation RPC request, maintains some “temporary state” associated to the path computed at time T1 and allows the client (MDSC) to request, at time T2, the setup of that path, if still available.



The solution we are considering is similar to the compute-only mode but, to avoid a stateful approach, is leveraging the path computation RPC and the separation between config and state DS, in line with the NMDA architecture.



At time T1, after having computed a path, as requested by a path computation RPC request, the server (PNC) also creates a compute-only te-tunnel in the state DS reporting the computed path. This would be similar to the stateful solution with the only difference that there is no te-tunnel in the config DS.



At time T2, the client (e.g., MDSC) can request to setup that path by creating a te-tunnel (not in compute-only mode) in the config DS using the same tunnel-name of the existing te-tunnel  in the state datastore: this will trigger the server (PNC) to setup the path that has been computed at time T1, if still available.



Question for the TEAS WG: do you think that a solution that allows requesting the setup a path previously computed, as described above, would be useful?



Thanks, Carlo, Francesco, Sergio and Italo

Italo Busi
Principal Optical Transport Network Research Engineer
[cid:image002.jpg@01D24740.915DFA60]
____________________________________________________________________________
Huawei Technologies Italia S.r.l.
Address:Centro Direzionale Milano 2, Palazzo Verrocchio, 3° Floor, 20090 Segrate (MI), Italy
Tel:+39 02 399948 32    Fax:   Mobile:+39 345 4721946
_____________________________________________________________________________
Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital €3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 257, Tower B, 20152 Milan. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A
_____________________________________________________________________________
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs you that the personal data contained in this email will be collected and treated for the acquisition of information preliminary to the conclusion of contracts, for the definition of the contractual relationship, as well as for the fulfillment of legal requirements related to civil, tax and accounting law or any other legal obligation to which Huawei may be subject. Personal data will not be subject to disclosure and spread unless otherwise required by law. Huawei will take appropriate security measures to protects personal data against loss, misuse disclosure or destruction of the information. Personal Data held may be transferred to countries outside the European Union, however Huawei Italia has put in place appropriate safeguards for the transfer of personal data to third countries by adopting the standard data protection clauses of the EU Commission. Personal Data are kept for a period necessary for the fulfillment of contract obligations unless otherwise required by law. You can exercise your rights under Art. 15 and following of  the GDPR (i.e. right of access, rectification, erasure, restriction, portability, object) by contacting Huawei at this email address: dataprotection@huawei.com<mailto:dataprotection@huawei.com> or through the following channel: www.huawei.com/en/personal-data-request<http://www.huawei.com/en/personal-data-request>;. You have also the right to lodge a complaint with the competent supervisory authorities. If you need any further information or have any queries on how Huawei process your personal data, please send an email to our Data Protection Officer at dpo@huawei.com<mailto:dpo@huawei.com>.The Data Controller is Huawei Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 257 Tower B, 20152.