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

Igor Bryskin <Igor.Bryskin@huawei.com> Wed, 21 November 2018 15:47 UTC

Return-Path: <Igor.Bryskin@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 34DE812E7C1 for <teas@ietfa.amsl.com>; Wed, 21 Nov 2018 07:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 MISr-VFZUrLW for <teas@ietfa.amsl.com>; Wed, 21 Nov 2018 07:47:38 -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 3CBCB128AFB for <teas@ietf.org>; Wed, 21 Nov 2018 07:47:38 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1912BC4CBE70C; Wed, 21 Nov 2018 15:47:35 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 21 Nov 2018 15:47:35 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.160]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0415.000; Wed, 21 Nov 2018 07:47:26 -0800
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>, Italo Busi <Italo.Busi@huawei.com>, "teas@ietf.org" <teas@ietf.org>
CC: "francesco.lazzeri@ericsson.com" <francesco.lazzeri@ericsson.com>, "carlo.perocchio@ericsson.com" <carlo.perocchio@ericsson.com>, "Beller, Dieter (Nokia - DE/Stuttgart)" <dieter.beller@nokia.com>
Thread-Topic: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation
Thread-Index: AQHUcV0g+cB7zvZQTkWKm9T3gpMmV6Va956A//96SwCAAI/jgP//eaug
Date: Wed, 21 Nov 2018 15:47:26 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C5A03B7@sjceml521-mbx.china.huawei.com>
References: <91E3A1BD737FDF4FA14118387FF6766B15910775@lhreml504-mbs> <etPan.5bda18d4.41979e04.ffa@localhost> <91E3A1BD737FDF4FA14118387FF6766B27658704@lhreml504-mbs> <0C72C38E7EBC34499E8A9E7DD00786391C5A0348@sjceml521-mbx.china.huawei.com> <DB6PR0701MB2727185C36AABEEBC6A0004991DA0@DB6PR0701MB2727.eurprd07.prod.outlook.com>
In-Reply-To: <DB6PR0701MB2727185C36AABEEBC6A0004991DA0@DB6PR0701MB2727.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.157.148]
Content-Type: multipart/related; boundary="_004_0C72C38E7EBC34499E8A9E7DD00786391C5A03B7sjceml521mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/pTkZnMpq2HnRMUDwPwkuzVjB7ok>
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: Wed, 21 Nov 2018 15:47:42 -0000

Lets assume that PCE has returned a path P and keeps a state for the path for a while. When it is requested with a new path computation, the PCE can “stick” the path P by projecting the resources required for the path (e.g. ODUk containers) onto the TE topology it uses for the path computation. In other words, the PCE can “assume in its mind” that path P is provisioned already. This way it would be guaranteed that no new path will be assigned with any resources of path P, as long as the same PCE is used.
A good analogy would be requesting a flight from Lufthansa, which will keep your reservation for 24 hours without you having to pay for the ticket right away.

Igor


From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:sergio.belotti@nokia.com]
Sent: Wednesday, November 21, 2018 10:31 AM
To: Igor Bryskin; Italo Busi; teas@ietf.org
Cc: francesco.lazzeri@ericsson.com; carlo.perocchio@ericsson.com; Beller, Dieter (Nokia - DE/Stuttgart)
Subject: RE: [Teas] Proposed enhancement to draft-ietf-teas-yang-path-computation

Hi Igor,
Our assumption , both for our “temporary state” and “compute-only mode” is whar also wrote in tunnel model draft: “a TE tunnel may be provisioned for the only purpose of computing a path and reporting it without the need to instantiate the LSP or commit any resources”.
With this assumption we leave open the remote possibility (how much percentage is not the context) that resources are taken by others and path is no more available. What we need to do in this case?
Our proposal is to re-compute a new path.
Sincerely , it is not fully clear what you mean with “sticky approach” , can you elaborate a bit ?
I suppose auto-discovered topology can be the native topology, right ?

Thanks
Sergio

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

Italo,

If the server keeps a state for a returned path, it can project said path onto auto-discovered TE topology before computing new paths (this is the essence of “sticky” path computation principle). Therefore, unless in the time interval since the response the resources required for the path are grabbed by some process independent of the server’s PCE in question, it won’t be possible for the returned path to become unavailable. In any case the probability of that would be far less than when returned to a sate -less PCE request.

Igor

From: Italo Busi
Sent: Wednesday, November 21, 2018 9:55 AM
To: Igor Bryskin; 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 Igor,

Thanks for your feedbacks

The proposal is quite similar to the stateful solution (in section 3.3.1 of draft-ietf-teas-yang-te) with the only difference that there is no te-tunnel in the config DS

In both cases, since the path reported in the state DS is based on an abstract topology, the server (PNC) also remembers which is the native path (physical path), within its native topology (physical topology), associated with that compute-only te-tunnel. This information is kept internally to the server (PNC) and does not have an impact on the YANG model design

Do you agree?

In both cases, we think that it can still be possible that the path computed at time T1 is no longer available at time T2. We noted that the behavior of the server (PNC) in this case is not described in section 3.3.1 of draft-ietf-teas-yang-te. We would propose that in this case, a new path is computed.

What do you think?

Sergio and Italo

From: Igor Bryskin
Sent: Wednesday, October 31, 2018 10:03 PM
To: 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

Not a bad idea, provided that the server is smart when supporting compute-only tunnels. For example it can use the "sticky" approach - project CO tunnel paths onto auto-discovered topology.

Igor
From:Italo Busi
To:TEAS WG,
Cc:Francesco Lazzeri,Belotti, Sergio (Nokia - IT/Vimercate),Carlo Perocchio,
Date:2018-10-31 12:20:35
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.