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

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

Hi Jean-Philippe, 

> -----Message d'origine-----
> De : JP Vasseur [mailto:[email-masked]] 
> Envoyé : lundi 6 novembre 2006 16:50
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]
> Objet : Re: Comments on draft-vasseur-pce-monitoring-01.txt
> 
> 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.

OK

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

Yes this could be useful. 

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

It could be based on all requests of the same nature (same objective function, constraint and correlation).

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 ?

Yes this would be useful if these are requests of the same nature.

Regards,

JL

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