Re: [Pce] Whither Stateless PCE?

Robert Varga <nite@hq.sk> Mon, 09 May 2016 13:18 UTC

Return-Path: <nite@hq.sk>
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 BF51E12B00A for <pce@ietfa.amsl.com>; Mon, 9 May 2016 06:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 RZvbxVE3LbKy for <pce@ietfa.amsl.com>; Mon, 9 May 2016 06:18:24 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8034712B030 for <pce@ietf.org>; Mon, 9 May 2016 06:18:24 -0700 (PDT)
Received: from [10.137.1.13] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 42C49243A0B; Mon, 9 May 2016 15:18:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1462799903; bh=I9Cwm/m0fBp+VVXFQRBt1wQzI/wJZu/ZBLSt9AW1Aos=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=XFbKyi0C/1AZ+1TWbomScMMVCY0kEFuFSjvqhZmzZywOJnq7/h3qvVIhaccNveotn pjKLTgGSSDVjmOhmGC0IBmpoGqsJKTU2XNNMKVeHX3uY4IxsTuM5qHcg73qjskgqCH 8vyawATx1AoIarUfJismA4qGDeuFBjcd7vvfqbZw=
To: stephane.litkowski@orange.com, "Zhangxian (Xian)" <zhang.xian@huawei.com>, "Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>, DUGEON Olivier IMT/OLN <olivier.dugeon@orange.com>
References: <091b01d19036$a22f2f10$e68d8d30$@olddog.co.uk> <CAB75xn7UKxZwq0zWXRopPyrtGfaYpP31jzMbGF3SsUB9CEQLuA@mail.gmail.com> <0a5a01d19088$9ddea060$d99be120$@olddog.co.uk> <4A79394211F1AF4EB57D998426C9340DD48CD06A@US70UWXCHMBA01.zam.alcatel-lucent.com> <28817_1460132965_5707DC65_28817_16160_1_5707DC64.1050707@orange.com> <4A79394211F1AF4EB57D998426C9340DD48CE32E@US70UWXCHMBA01.zam.alcatel-lucent.com> <5714D9D9.9070506@orange.com> <4A79394211F1AF4EB57D998426C9340DD48D8419@US70UWXCHMBA01.zam.alcatel-lucent.com> <C636AF2FA540124E9B9ACB5A6BECCE6B7DEA7171@SZXEMA512-MBS.china.huawei.com> <6825_1462799211_57308B6B_6825_6445_1_78306064-4402-4cf6-979b-ec1571b34e18@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Robert Varga <nite@hq.sk>
X-Enigmail-Draft-Status: N1110
Message-ID: <c23944b3-ba1d-2d0e-eb7a-cbfbd9796496@hq.sk>
Date: Mon, 09 May 2016 15:18:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <6825_1462799211_57308B6B_6825_6445_1_78306064-4402-4cf6-979b-ec1571b34e18@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="OwHDeEnPmd11t7tFBq5g79l9ID6WvqP5u"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/VBLiRzWctGIeQyaoNw2IyCTMMfQ>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] Whither Stateless PCE?
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, 09 May 2016 13:18:29 -0000

On 05/09/2016 03:06 PM, stephane.litkowski@orange.com wrote:
> Hi Xian,
> 
>  
> 
> Regarding the METRIC object, the issue is not having the Object in the
> PCRpt (which already works). The issue is that the metric object will
> reflect the operational state of the LSP rather than it’s configuration.
> 
> The best example may be :
> 
> PCC is configured to use IGP metric with a cost bound to 20.
> 
> In the PCRpt, it will send in the METRIC object the operational values
> of the LSP, so the metric may be anything below 20 (e.g. 14) and B=0 and
> we will not have any information about the cost boundary constraint, so
> the PCE will not be able to fullfill this constraint when computing the
> path for the PCC.

Hello,

This looks like the 'ERO/RRO in PCRpt' discussion we have had with
Julien. While the ERO/RRO split makes this a non-issue in that case, we
seem to lack a general mechanism to discern 'intended' and 'effective'
state, notably in the case when the PCE needs to recover the intended
state from the PCC.

Does that sum up the problem?

Thanks,
Robert