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

[Julien Meuric <[e-mail]>]

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:[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 >