Subject: [Pce] Comments on draft-vasseur-pce-monitoring-01.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 6 Nov 2006 15:58:39 +0100

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-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Nov 2006 10:49:30 -0500

Hi Jean-Louis,

> This is a relevant draft.

Thanks. In line,

> list of lsp-requests should be added.

OK let's discuss this for the next revision.

> recording in a reply), hence I would suggest defining this object is a

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.

> 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.

> This is not clear. To me it is used in the PCMonReq to enforce the  

OK will clarify.

> May be you could distinguish the computation time and the response  

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 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 ?

> or based on actual computation.

Good point. Next revision.

> congestion (request buffer full...).

Also a good point.

> "If the G flag of the MONITORING Object if cleared then this field  

Thanks for these useful comments.

Cheers,

JP.