Re: [Pce] Whither Stateless PCE?

[Olivier Dugeon <[e-mail]>]

Dear Mustapha,

You catch a good point regarding the original constraints that are not 
carry by the PCRpt message. Thus, if we used a standard PCReq message 
without the D-delegate flag set, there is a risk that the PCE considers 
this request as a stateless one and don't keep track of the original 
request, and consequently, original constraints.

So, is it preferable to set de D-delegate flag in the PCReq message to 
tell the PCE to keep in memory the original constraints for further 
usage, or, is the 'STATEFUL-PCE-CAPABILITY' TLV in Open message is 
sufficient for the PCE to know that it must keep track of any requests? 
I prefer the first option as it allows a per request configuration while 
the second enables the memorization globally for all requests.

Regards,

Olivier

Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit :
>
> Hi Olivier,
>
> Good summary indeed. I was worried about interop testing when I sent 
> the original email to the list in December 2014.
>
> I just wanted to comment on a couple of things:
>
> 1.You are correct that the LSP object which has the D-delegate flag is 
> allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I 
> however think it is more appropriate to do the delegation in the 
> subsequent PCRpt message once the LSP path is programmed by PCC 
> following the PCRep message from PCE. This is because it is at that 
> time that the LSP is being synchronized with the PCE LSP database.
>
> 2.The PCRpt message does not carry the original constraints of the LSP 
> (Bandwidth, Metric, and LSPA objects). It can carry the operational 
> values of the Bandwidth and Metric objects used by the last computed 
> path in the router. So, even if you have a PCE which reacted to the 
> PCRpt message and computed a new path, it will not get the appropriate 
> constraints included. That is why the PCReq/PCRep sequence before 
> delegating the LSP is needed.
>
> Regards,
>
> Mustapha.
>
> *From:*EXT [e-mail] [mailto:[e-mail]]
> *Sent:* Friday, April 08, 2016 12:29 PM
> *To:* Aissaoui, Mustapha (Nokia - CA); [e-mail]; 'Dhruv Dhody'
> *Cc:* [e-mail]
> *Subject:* Re: [Pce] Whither Stateless PCE?
>
> 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:[e-mail]] *On Behalf Of *EXT Adrian
>     Farrel
>     *Sent:* Thursday, April 07, 2016 12:48 AM
>     *To:* 'Dhruv Dhody'
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]] *On Behalf Of *Dhruv Dhody
>     *Sent:* 06 April 2016 23:07
>     *To:* Farrel Adrian
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail]
>     <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/pce
>
>
>
>
>     _______________________________________________
>
>     Pce mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     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.