Re: [Pce] Whither Stateless PCE?
<olivier.dugeon@orange.com> Fri, 08 April 2016 16:29 UTC
Return-Path: <olivier.dugeon@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 E698312D09A for <pce@ietfa.amsl.com>; Fri, 8 Apr 2016 09:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 aoYbmEVg01sU for <pce@ietfa.amsl.com>; Fri, 8 Apr 2016 09:29:29 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F1C12D119 for <pce@ietf.org>; Fri, 8 Apr 2016 09:29:26 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6F9EE3B4448; Fri, 8 Apr 2016 18:29:25 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 487154C048; Fri, 8 Apr 2016 18:29:25 +0200 (CEST)
Received: from [10.193.71.24] (10.168.234.3) by OPEXCLILM33.corporate.adroot.infra.ftgroup (10.114.31.58) with Microsoft SMTP Server (TLS) id 14.3.279.2; Fri, 8 Apr 2016 18:29:25 +0200
To: "Aissaoui, Mustapha (Nokia - CA)" <mustapha.aissaoui@nokia.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>
References: <091b01d19036$a22f2f10$e68d8d30$@olddog.co.uk> <CAB75xn7UKxZwq0zWXRopPyrtGfaYpP31jzMbGF3SsUB9CEQLuA@mail.gmail.com> <0a5a01d19088$9ddea060$d99be120$@olddog.co.uk> <4A79394211F1AF4EB57D998426C9340DD48CD06A@US70UWXCHMBA01.zam.alcatel-lucent.com>
From: olivier.dugeon@orange.com
Organization: Orange Labs
Message-ID: <28817_1460132965_5707DC65_28817_16160_1_5707DC64.1050707@orange.com>
Date: Fri, 08 Apr 2016 18:29:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD48CD06A@US70UWXCHMBA01.zam.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------010206000905080101080607"
X-Originating-IP: [10.168.234.3]
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.8.152416
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/SJAnAW8fkc0Npyz2mfjxS0--hTg>
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: Fri, 08 Apr 2016 16:29:33 -0000
Hello all, IMHO the discussion must be split into is 2 different subjects: 1/ PCInit message could be seen as an independent message compared to other PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit message after a request that comes from another interface (e.g. a RestConf API) instead of PCReq that comes from the router itself through PCEP. In fact, when you configure a tunnel on the router, only the path computation part is requested to the PCE. Complements of tunnel configuration still remain in the router configuration. In case of PCInit, all information must be provided to the router. This could be for example the traffic steering. So, IMHO, it is normal that the PCInit message evolves through extensions different from the other PCEP messages, and in particular PCReq, as it is not triggered by the same entity, i.e. an external component instead the PCC router itself. 2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 will continue to be mandatory for stateful both passive and active mode even if it needs clarification in the draft. Let me explain. In passive stateful, a PCReq/PCRep sequence is drawn in Figure 7 of the pce stateful draft prior to the PCRpt message Now, the ambiguity comes from the active stateful mode and figure 8. Why is the PCReq/PCRep sequence not mentioned? Of course the tunnel is delegated in this mode, but, the delegation object has been added as an extension to the PCReq message in the same draft. So, IMHO, at the creation of the tunnel, the draft must precise that a PCReq/PCRep exchange with delegation=1 must be used prior to the PCRpt to be coherent with RFC 5440 and passive stateful mode. The problem occured during our evaluation of commercial products on which we made interoperability tests. Indeed we observed different behaviours that are due to the draft ambiguity and conduct to some interoperability issues. The different cases are as follow: - a/ - PCReq/PCRep exchange to obtain a valid ERO before the PCRpt message - b/ - PCReq message to obtain a valid ERO but with no reaction from the PCE which is not conform to RFC5440 - c/ - PCRpt with empty ERO (looks strange. What is the meaning of an Empty ERO ? a loose path ? no path ? )/PCupd to get a valid path which overlaps with standard RFC5440 PCReq/PCRep. - d/ - PCRpt with empty ERO and no PCUpd leaving the tunnel down. Thus, PCC/PCE that used PCRpt/PCupd messages for active stateful mode are incompatible with PCC/PCE that used standard PCReq/PCrep exchange. We could not mix both behaviours (PCC that use PCReq message with PCE that react to PCRpt with empty ERO and reciprocally). The problem occurs only at the creation of the tunnel. Once created and up the tunnel is reported and updated by means of PCRpt / PCupd messages correctly in all cases. To summarize: PCInit message could leave independently from other messages. PCReq is the basis of PCE and is mandatory in all use cases included the active stateful mode, but this need to be clarify in the pce stateful draft. Regards Olivier Le 07/04/2016 23:22, Aissaoui, Mustapha (Nokia - CA) a écrit : > > 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 > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- Re: [Pce] Whither Stateless PCE? Robert Varga
- Re: [Pce] Whither Stateless PCE? Julien Meuric
- Re: [Pce] Whither Stateless PCE? Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Whither Stateless PCE? Julien Meuric
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Ina Minei
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Ina Minei
- [Pce] Whither Stateless PCE? Adrian Farrel
- Re: [Pce] Whither Stateless PCE? Dhruv Dhody
- Re: [Pce] Whither Stateless PCE? Adrian Farrel
- Re: [Pce] Whither Stateless PCE? Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Whither Stateless PCE? olivier.dugeon
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Aissaoui, Mustapha (Nokia - CA)
- [Pce] 答复: Whither Stateless PCE? Fatai Zhang
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Olivier Dugeon
- Re: [Pce] Whither Stateless PCE? Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Whither Stateless PCE? Julien Meuric
- [Pce] Linking Stateful and Stateless Capabilities… Julien Meuric
- Re: [Pce] Linking Stateful and Stateless Capabili… Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Whither Stateless PCE? Zhangxian (Xian)
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Robert Varga
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Ina Minei
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Olivier Dugeon
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Olivier Dugeon
- Re: [Pce] Whither Stateless PCE? Ina Minei
- Re: [Pce] Whither Stateless PCE? Robert Varga
- Re: [Pce] Whither Stateless PCE? Olivier Dugeon
- Re: [Pce] Whither Stateless PCE? Robert Varga
- Re: [Pce] Whither Stateless PCE? stephane.litkowski
- Re: [Pce] Whither Stateless PCE? Aissaoui, Mustapha (Nokia - CA)
- Re: [Pce] Whither Stateless PCE? Robert Varga