Subject: Re: [Pce] Whither Stateless PCE?

From: Julien Meuric <[email-masked]>
Date: Tue, 3 May 2016 14:15:34 +0200

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 - [email-masked]:
> > 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:[email-masked] 
[mailto:[email-masked]] *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 <[email-masked] > <mailto:[email-masked]>> 
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 >

---

From: Julien Meuric <[email-masked]>
Date: Tue, 3 May 2016 14:32:21 +0200

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 - [email-masked]:
> > 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:[email-masked]] *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 [email-masked] > 
<mailto:[email-masked]> > [mailto:[email-masked]] 
*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:[email-masked]] *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:[email-masked] <mailto:[email-masked]> > 
[mailto:[email-masked]] *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 <[email-masked] > <mailto:[email-masked]>> 
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.

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Tue, 3 May 2016 14:29:13 +0000

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:[email-masked]]
> Sent: Tuesday, May 03, 2016 8:32 AM
> To: Aissaoui, Mustapha (Nokia - CA); [email-masked]
> Subject: Linking Stateful and Stateless Capabilities [Was: Whither Stateless PCE?]
> 
> Hi all,
> 
> 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
> 
> 
> 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:[email-masked]] *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, > >
> : > > Hi Olivier, > > Good summary indeed. I was worried about interop testing
> when I sent > the original email to the list in December 2014. >
> 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. > >
> 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 [email-masked] >
> *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
> 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
> 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-
> [email-masked]] *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 > > > >
> [mailto:[email-masked]] *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 <[email-masked] >
> <mailto:[email-masked]>>
> 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 >
>

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 5 May 2016 06:33:25 +0000

Hi,

   I would like to first thank Olivier and Mustapha for bringing such good comments/discussions, based on inter-op test.  With your help, hope we can clear the ambiguity very soon.

With regard to the 2nd point raised below by Mustapha:
＂
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.＂

The capability of carrying Metric/LSPA in PCRpt message is already allowed (see https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-14#section-6.1).  If you think there is lack of text explanation of the motivation behind, we should add some to make it clearer.

Regards,
Xian

From: Pce [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: 2016年4月19日 4:00
To: EXT Olivier Dugeon; [email-masked]; 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

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:[email-masked]]
Sent: Monday, April 18, 2016 8:58 AM
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

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 [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, April 08, 2016 12:29 PM
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Thursday, April 07, 2016 12:48 AM
To: 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________

Pce mailing list

[email-masked]<mailto:[email-masked]>

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.

---

From: <[email-masked]>
Date: Mon, 9 May 2016 13:06:45 +0000

Hi Xian,

Regarding the METRIC object, the issue is not having the Object in the PCRpt (which already works). The issue is that the metric object will reflect the operational state of the LSP rather than it’s configuration.
The best example may be :
PCC is configured to use IGP metric with a cost bound to 20.
In the PCRpt, it will send in the METRIC object the operational values of the LSP, so the metric may be anything below 20 (e.g. 14) and B=0 and we will not have any information about the cost boundary constraint, so the PCE will not be able to fullfill this constraint when computing the path for the PCC.

Hope it helps,

Stephane

From: Pce [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Thursday, May 05, 2016 08:33
To: Aissaoui, Mustapha (Nokia - CA); DUGEON Olivier IMT/OLN
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Hi,

Regards,
Xian

From: Pce [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: 2016年4月19日 4:00
To: EXT Olivier Dugeon; [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hi Olivier,

Regards,
Mustapha.

Dear Mustapha,

Regards,

Olivier

Regards,
Mustapha.

Hello all,

Regards

Olivier

Regards,
Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.

---

From: Robert Varga <[email-masked]>
Date: Mon, 9 May 2016 15:18:11 +0200

On 05/09/2016 03:06 PM, [email-masked] wrote:
> Hi Xian,
> 
>  
> 
> Regarding the METRIC object, the issue is not having the Object in the
> PCRpt (which already works). The issue is that the metric object will
> reflect the operational state of the LSP rather than it’s configuration.
> 
> In the PCRpt, it will send in the METRIC object the operational values
> of the LSP, so the metric may be anything below 20 (e.g. 14) and B=0 and
> we will not have any information about the cost boundary constraint, so
> the PCE will not be able to fullfill this constraint when computing the
> path for the PCC.

Hello,

This looks like the 'ERO/RRO in PCRpt' discussion we have had with
Julien. While the ERO/RRO split makes this a non-issue in that case, we
seem to lack a general mechanism to discern 'intended' and 'effective'
state, notably in the case when the PCE needs to recover the intended
state from the PCC.

Does that sum up the problem?

Thanks,
Robert

---

From: <[email-masked]>
Date: Mon, 9 May 2016 13:25:55 +0000

Yes, exactly.
Depending on the exact level of detail we want from the PCC, we may need possibly three different states :
- intended (configuration => may be partially/totally received from PCE)
- effective (configuration => what has been really taken into account by PCC in term of config) => this one may be necessary in case some configuration option may be sent by the PCE but not taken into account by PCC.
- operational (ops state => what is the current state of the computed path)

-----Original Message-----
From: Robert Varga [mailto:[email-masked]] 
Sent: Monday, May 09, 2016 15:18
To: LITKOWSKI Stephane OBS/OINIS; Zhangxian (Xian); Aissaoui, Mustapha (Nokia - CA); DUGEON Olivier IMT/OLN
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

On 05/09/2016 03:06 PM, [email-masked] wrote:
> reflect the operational state of the LSP rather than it's configuration.
> 
> of the LSP, so the metric may be anything below 20 (e.g. 14) and B=0 
> and we will not have any information about the cost boundary 
> constraint, so the PCE will not be able to fullfill this constraint 
> when computing the path for the PCC.

Hello,

This looks like the 'ERO/RRO in PCRpt' discussion we have had with Julien. While the ERO/RRO split makes this a non-issue in that case, we seem to lack a general mechanism to discern 'intended' and 'effective'
state, notably in the case when the PCE needs to recover the intended state from the PCC.

Thanks,
Robert