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> > [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 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-boun...@ietf.org] *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:*dhruvdh...@gmail.com <mailto:dhruvdh...@gmail.com> >
[mailto:dhruvdh...@gmail.com] *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 <adr...@olddog.co.uk > <mailto:adr...@olddog.co.uk>>
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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
