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

[Aissaoui, Mustapha (Nokia - CA)]

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:julien.meu...@orange.com]
> Sent: Tuesday, May 03, 2016 8:32 AM
> To: Aissaoui, Mustapha (Nokia - CA); pce@ietf.org
> 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 - mustapha.aissa...@nokia.com:
> > > 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:olivier.dug...@orange.com] *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 olivier.dug...@orange.com >
>  > [mailto:olivier.dug...@orange.com]
> *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 
> computati

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

[Julien Meuric]

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 - mustapha.aissa...@nokia.com:
> 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:olivier.dug...@orange.com] *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 olivier.dug...@orange.com > 
 > [mailto:olivier.dug...@orange.com] 
*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 activ