Hi Jean-Philippe,
This is a relevant draft.
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.
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.
>"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..."
-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...
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?
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.
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.
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 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
Regards,
JL
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
