Re: [Pce] Linking Stateful and Stateless Capabilities [Was: Whither Stateless PCE?]

["Aissaoui, Mustapha (Nokia - CA)" <[e-mail]>]

Hi Julien,
I will work with Olivier to prepare a proposed text to address the below issues in draft-ietf-pce-stateful-pce. We will post it for the authors and the WG to enhance.

Regards,
Mustapha.

> -----Original Message-----
> From: EXT Julien Meuric [mailto:[e-mail]]
> Sent: Tuesday, May 03, 2016 8:32 AM
> To: Aissaoui, Mustapha (Nokia - CA); [e-mail]
> Subject: Linking Stateful and Stateless Capabilities [Was: Whither Stateless PCE?]
> 
> Hi all,
> 
> [New title to help editors of stateful I-Ds to catch up.]
> 
> It appears that there is still some shadow on the main stateful I-D. We should make
> sure that any reader has a good understanding of what is history behavior and
> what is not, without assuming incremental extensions of IETF protocols is known-
> enough to guarantee backward compatibility.
> 
> Mustapha, if you have a couple of clarifying sentences to share, so as to address
> your concerns, that would be valuable.
> 
> Thanks,
> 
> Julien
> 
> 
> Apr. 18, 2016 - [e-mail]:
> > > Hi Olivier, > > It is one option for sure. In general,
> implementations of stateful > PCE should be able of caching the constraints
> received in the PCReq > message for some period of time to give a chance for a
> potential > follow-up PCRpt message. Even if you set the D-flag in the PCReq >
> message, there is no guarantee that a PCRpt will follow and as such a > PCE
> implementation will have to flush that information from its cache > at some point in
> time. > > > > In addition, I think it is worth considering sending the constraints > in
> a PCRpt message in duplicate Metric/LSPA objects with the P-flag > set. This is in
> addition to the same objects containing the > operational values.
> This can be useful in the case where the initial > path was computed by the router
> and it is active and the user is > delegating it. The PCE at that point in time will not
> compute a path > immediately but will save the original constraints in the PCRpt >
> message for the next time it needs to update the path. > > > > Regards, > >
> Mustapha. > > > > *From:*EXT Olivier Dugeon
> [mailto:[e-mail]] *Sent:* > Monday, April 18, 2016 8:58 AM > >
> > > 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]> > [mailto:[e-mail]]
> *Sent:* Friday, April 08, 2016 > 12:29 PM > > > > 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-
> [e-mail]] *On Behalf Of *EXT Adrian > Farrel *Sent:* Thursday, April 07,
> 2016 12:48 AM > > > > 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 > > > > 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 >
>