Re: [Pce] Feed-back on Monitoring ?

Wed, 01 Nov 2006 13:20:27 -0800

Hi Eiji,

On Oct 24, 2006, at 10:38 AM, Eiji Oki wrote:

Hi JP, 

The ID looks very great. 

Thanks for your feed-back.


I have several comments.

1. Section 3.2: The last sentense 
   The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD-
   BALANCING objects are defined in [I-D.ietf-pce-pcep].
is not neccessary, as these objects do not appear in PCMonRep.


Indeed, it has been removed, thanks.

2. Section 4.1 describes 
   P (Processing Time) - 1 bit: the P bit of the MONITORING object
   carried in a PCMonReq message is set to indicate that the processing...

"or a PCReq message" would be added after "a PCMonReq message".


Good catch, added, thanks.

3. Section 4.3 describes
   When the processing time is requested in addition to a path
   computation, the PROC-TIME object always report the actual processing
   time for that request and thus the E bits MUST be cleared.

Is it possible to define "actulal" Min- Max- Average- procssing time
with E=0?

No because for the Min, Max, Average and Variance the values are computed based on some history, they're not estimated. The case of an estimated metric is when the request relates to a particular TE LSP path computation (as opposed to a general request). I clarified:
"When a request is specific (related to a particular TE LSP path computation), the G bit MUST be cleared and the Min-processing-time, Max-processing-time, Average-processing-time and Variance-processing-time MUST be set to 0x00000000."

Otherwise, when E is cleared, Min- Max- Average- procssing
time MUST be set to 0x00000000. In other words, 
If the G flag of the MONITORING object is set then E bit MUST be cleared.
Please clarify it.


Yes, actually there's no such E bit for the Min, Max, Average and Variance (removed). The E bit is only relevant for specific request for which the G bit is cleared.

Does that clarify ?

4. Section 4.1

  C (Check) - 1 bit: when set, this indicates that the performance
   metric of interest is the PCE's availability.

What does the PCE's availablity mean?

This is a way to ensure that the PCE is alive. This way, you can for example, check a path computation chain by specifying a set of PCE-ID. I will replace "availability" by "liveness".

If a specific TE LSP computation is requested, does it mean that PCE has
the ability to compute the path with the specified constraints?

Yes indeed, in this case a PCC can request the computation of a path + gather the processing time on each hop.

In case of the general computation, does it mean that PCE is alive or
not?
Please clarify it.

I'm not sure to see your question ?

Thanks for your comments.

JP.


Thank you.
Eiji

On Fri, 20 Oct 2006 08:30:06 -0400
JP Vasseur <[EMAIL PROTECTED]> wrote:

Hi,

See below a new ID related to the monitoring of PCE-based path  
computation architecture so as to required various performance  
metrics such as liveness verification of the various elements of a  
path computation chain, processing time spent on path computation at  
each hop (for performance monitoring or troubleshooting, ...).

Comments and opinions are most welcome.

Thanks.

JP.


Begin forwarded message:

Date: October 20, 2006 2:50:01 AM EDT
Subject: I-D ACTION:draft-vasseur-pce-monitoring-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title : A set of monitoring tools for Path Computation Element  
based Architecture
Author(s) : J. Vasseur
Filename : draft-vasseur-pce-monitoring-01.txt
Pages : 16
Date : 2006-10-19

A Path Computation Element (PCE) based architecture has been
   specified for the computation of Traffic Engineering (TE) Label
   Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) networks in the context of single or
   multiple domains (where a domain is referred to as a collection of
   network elements within a common sphere of address management or  
path
   computational responsibility such as IGP areas and Autonomous
   Systems).  In such PCE-based environment it is thus critical to
   monitor the state of the path computation chain and potentially
   gather various performance metrics with regards to the set of
   involved PCE(s) that can be used for performance monitoring and
   troubleshooting purposes.  This document specifies procedures and
   extensions to the Path Computation Element Protocol (PCEP) in order
   to gather such information.

A URL for this Internet-Draft is:
monitoring-01.txt

To remove yourself from the I-D Announcement list, send a message to
[EMAIL PROTECTED] with the word unsubscribe in the body of
the message.
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-vasseur-pce-monitoring-01.txt".

A list of Internet-Drafts directories can be found in

Internet-Drafts can also be obtained by e-mail.

Send a message to:
In the body type:
"FILE /internet-drafts/draft-vasseur-pce-monitoring-01.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>

_______________________________________________
I-D-Announce mailing list


_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce

Reply via email to