Re: [Pce] Whither Stateless PCE?

"Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com> Thu, 07 April 2016 21:22 UTC

Return-Path: <mustapha.aissaoui@nokia.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 E4DC512D721 for <pce@ietfa.amsl.com>; Thu, 7 Apr 2016 14:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ko78yaCcGXEj for <pce@ietfa.amsl.com>; Thu, 7 Apr 2016 14:22:23 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 A1B6012D65D for <pce@ietf.org>; Thu, 7 Apr 2016 14:22:16 -0700 (PDT)
Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id BFB642117F27C; Thu, 7 Apr 2016 21:22:12 +0000 (GMT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u37LMEta013033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 21:22:15 GMT
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u37LMD8l002765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 21:22:14 GMT
Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.2]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 17:22:13 -0400
From: "Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>
Thread-Topic: [Pce] Whither Stateless PCE?
Thread-Index: AdGQNhyPAKWwZo0PTL2c2Fgzw0+kjwAPAQoAAA4AeYAAExO68A==
Date: Thu, 07 Apr 2016 21:22:13 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340DD48CD06A@US70UWXCHMBA01.zam.alcatel-lucent.com>
References: <091b01d19036$a22f2f10$e68d8d30$@olddog.co.uk> <CAB75xn7UKxZwq0zWXRopPyrtGfaYpP31jzMbGF3SsUB9CEQLuA@mail.gmail.com> <0a5a01d19088$9ddea060$d99be120$@olddog.co.uk>
In-Reply-To: <0a5a01d19088$9ddea060$d99be120$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340DD48CD06AUS70UWXCHMBA01z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/hFzso79-tTIQFynaH5HLKS__IpY>
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: Thu, 07 Apr 2016 21:22:37 -0000

Hi Adrian,
I raised in December 2014 the technical issue in draft-ietf-pce-stateful-pce that a PCC must be able to convey the original parameters (constraints) of the LSP path (Bandwidth, Metric, and LSPA objects) using a PCReq message to a PCE and subsequently delegate the LSP to PCE using the PCRpt message. Otherwise, when the LSP is delegated to PCE only the operational values of these parameters can be included in the PCRpt message. The latter means that the PCE will update the path without knowing exactly the original parameters.

For me, PCReq/PCRep are an integral part of operating an LSP in stateful mode.

Here is the link to the archived thread:
https://mailarchive.ietf.org/arch/search/?email_list=pce&so=-date&q=%22+Path+Computation+Request+in+Active+Stateful+PCE%22

Regards,
Mustapha.

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of EXT Adrian Farrel
Sent: Thursday, April 07, 2016 12:48 AM
To: 'Dhruv Dhody'
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

I think you are probably right, Dhruv.

But referencing the ways in which customers deploy may be a little limiting.
To say PCE is widely deployed (even after all these years) may be an exaggeration.
Although we do have some clues about what is currently being pushed for deployment.

I think you have mainly grasped my point, however. We need to understand which extensions are definitely only needed in one mode or another, and which should be done in all modes (either because they are needed or because we don't know).

OTOH, I suppose TLVs are just TLVs. Once you specified the TLV it is not rocket science to include it in a message. In fact, it is probably one line of text to include it and only a short paragraph to describe additional processing in other modes once you have described how it is used in one mode.

Where does that leave us?

Adrian

From: dhruvdhody@gmail.com<mailto:dhruvdhody@gmail.com> [mailto:dhruvdhody@gmail.com] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Whither Stateless PCE?

Hi Adrian,

Even in the brave new world of Stateful PCE, PCReq and PCRep messages do play a role in the passive stateful PCE mode. PCReq/PCRep also play a crucial role in the inter-domain and inter-layer context in the new proposal like stateful H-PCE.

At the same time mandating that every extension (say SFC) must also be specified in a stateless manner when no customer deploy in such a way, might be overkill.

Perhaps we need to look at it case by case!

Dhruv

On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:
Once upon a time, in a working group far, far away, PCE was basically stateless.
PCE acted in response to questions asked by PCCs.

These days, everyone is excited by stateful PCEs and there is a lot of
initiation (of LSPs or of control of LSPs).

In the jabber room during today's meeting Ravi noted that not a lot of the new
drafts (maybe none of them) talk about PCReq messages. This raises the question
in our minds as to whether stateless PCE is obsolete.

If (and only if) this mode of PCE usage has gone out of fashion, we *might*
consider cleaning up the protocol and architecture so that we don't need to make
protocol extensions to PCReq and PCRep messages when we make extensions to
PCInit messages.

Thoughts?

Adrian

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce