Re: [Pce] Whither Stateless PCE?

Julien Meuric <julien.meuric@orange.com> Tue, 03 May 2016 12:15 UTC

Return-Path: <julien.meuric@orange.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 AB68012D7BB for <pce@ietfa.amsl.com>; Tue, 3 May 2016 05:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level:
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] autolearn=no 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 3fsQNyhwtan5 for <pce@ietfa.amsl.com>; Tue, 3 May 2016 05:15:49 -0700 (PDT)
Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCE12D7BE for <pce@ietf.org>; Tue, 3 May 2016 05:15:35 -0700 (PDT)
Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 07E2D7CC003; Tue, 3 May 2016 14:15:35 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id EDDAA7CC001; Tue, 3 May 2016 14:15:34 +0200 (CEST)
Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Tue, 3 May 2016 14:15:34 +0200
To: adrian@olddog.co.uk
References: <091b01d19036$a22f2f10$e68d8d30$@olddog.co.uk> <CAB75xn7UKxZwq0zWXRopPyrtGfaYpP31jzMbGF3SsUB9CEQLuA@mail.gmail.com> <0a5a01d19088$9ddea060$d99be120$@olddog.co.uk>
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
Message-ID: <57289666.60600@orange.com>
Date: Tue, 03 May 2016 14:15:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <0a5a01d19088$9ddea060$d99be120$@olddog.co.uk>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/U2OwuLP3wVT_0LdN9xoYOuulSFo>
Cc: 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: Tue, 03 May 2016 12:15:50 -0000

Hi Adrian,

Based on the evolution of this thread, it looks like it leaves us with 
the following guidelines:
- The case by case basis looks reasonable and should prevail;
- Extensions should focus on what is (eventually) useful;
- The scope of each work should be explicitly mentioned in I-Ds.

I hope this is an acceptable answer to your question.

Regards,

Julien


Apr. 07, 2016 - adrian@olddog.co.uk:
> > 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] *On Behalf > Of *Dhruv Dhody *Sent:* 06 
April 2016 23:07 > > > > 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 >