Hi Jean-Louis,
On Nov 6, 2006, at 9:58 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:
Hi Jean-Philippe,
This is a relevant draft.
Thanks. In line,
Find below some comments:
-Section 3.1: PCMonReq
One may want to gather performance metrics with syncrhonized path
computations (e.g. Diverse Path computation).
Hence the PCMonReq message should IMO be extended. The SVEC object
and a
list of lsp-requests should be added.
OK let's discuss this for the next revision.
Actually the PCE id object is required for many other applications
(e.g.
to fit inter-area requirements of PCE list enforcement in a request
and
recording in a reply), hence I would suggest defining this object is a
separate draft.
No objection to this, I put it there for now but indeed we could have
it in a separate ID in which we could address the other inter-area
requirements.
"A PCMonReq message is sent to gather various performance metrics
along
a path computation
chain. Such metrics may relate to a specific path computation chain
encoded in the form of a
series of PCE-ID objects defined in section 4.2. Alternatively it may
be desired to collect
such performance metrics along the path computation chain involved to
compute a TE-LSP".
Actually it appears here that the two options (series of PCE ids and
TE-LSP) are exclusive.
One may actually want to collect the metrics along a specific PCE
chain
for a given TE-LSP.
So you may have both a PCE-id list and an lsp-request within a
PCMonReq.
That would be good to add a fourth example to illustrate this case:
"PCC3 requests to gather performance metrics along the specific path
computation chain PCE1-PCE2-PCE3, for the computation of T1..."
Absolutely, ambiguous wording since this was the intention. Will fix
that in the next revision.
-Section 4.2
First sentence: "the PCE-ID object is used in a PCMonReq to record the
IP address of the PCE for which performance metrics are collected"...
This is not clear. To me it is used in the PCMonReq to enforce the
chain
of PCEs to be used...
OK will clarify.
Section 4.3
Current-Processing time: Does this represents only the path
computation
time, or does it also account for the waiting time in the request
queue?
May be you could distinguish the computation time and the response
time?
The intent was to report the processing time=waiting time+processing
time.
Do you think that both might be useful (for example in case of CPU
intensive cases to differentiate the waiting time from the actual
computation time) ?
Min/Max/Average/Variance processing time
"If the G flag is cleared then this field must be set to 0..."
Why such restriction? It may be useful to know the expected
min/max/average processing time for a specific LSP.
Well the average is computed over a set of requests ... so it cannot
really apply to a specific request. Similarly, with regards to the
min. max and variance they are computed over a set of requests. So
when these fields apply to general requests.
That said, we could extend to request to get the (estimated) time for
a specific request and in addition collect performance metrics for a
set of requests that have been processed in the past. Thoughts ?
E bit control: It would be good to add a flag in the MONITORING object
that would allow a PCC to indicate whether the time should be
estimated
or based on actual computation.
Good point. Next revision.
General comment:
It may be useful to record the congestion status of a PCE chain.
Hence I would suggest adding a flag in the MONITORING object, the S
flag: Saturation, when set this indicates that the congestion is a
metric of interest.
And a CONGESTION Object could be defined, that would indicate the
congestion satus, and optionally, if policy permits the reasons for
the
congestion (request buffer full...).
Also a good point.
Also some minor edits:
Section 3.2
The format of a PCReq message is as follows => The format of a
PCMonRep
message is as follows
^^^^^
^^^^^^^^
Section 3.2
Remove "the SVEC, RP...are defined in [I-D.ietf-pce-pcep]"
Section 4.2, first line
The PCE-ID object is used in a PCMonReq or a message
=> The PCE-ID object is used in a PCMonReq or a PCReq message
^^^^^
Section 4.3
"If the G flag of the MONITORING Object if cleared then this field
MUST
be set to 0x00000000."
^^is
Thanks for these useful comments.
Cheers,
JP.
Regards,
JL
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
