Hi Jean-Philippe, > -----Message d'origine----- > De : JP Vasseur [mailto:[EMAIL PROTECTED] > Envoyé : lundi 6 novembre 2006 16:50 > À : LE ROUX Jean-Louis RD-CORE-LAN > Cc : [EMAIL PROTECTED] > 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 protected] https://www1.ietf.org/mailman/listinfo/pce
