Subject: Re: [Pce] Feed-back on Monitoring ?

From: JP Vasseur <[email-masked]>
Date: Wed, 1 Nov 2006 16:18:05 -0500

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-masked]> 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:
>>
>>> From: [email-masked]
>>> Date: October 20, 2006 2:50:01 AM EDT
>>> To: [email-masked]
>>> Subject: I-D ACTION:draft-vasseur-pce-monitoring-01.txt
>>> Reply-To: [email-masked]
>>>
>>> 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:
>>> http://www.ietf.org/internet-drafts/draft-vasseur-pce-
>>> monitoring-01.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email-masked] with the word unsubscribe in the  
>>> body of
>>> the message.
>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>>> announce
>>> 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
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> 	[email-masked].
>>> 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-masked]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>

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

---

From: Eiji Oki <[email-masked]>
Date: Thu, 02 Nov 2006 15:23:34 +0900

Hi JP, 

Thanks for your clarifications.
Please ignore my last question. 

Thank you.
Eiji

On Wed, 1 Nov 2006 16:18:05 -0500

---

From: JP Vasseur <[email-masked]>
Date: Wed, 1 Nov 2006 16:51:45 -0500

Hi Mach,

On Oct 31, 2006, at 4:36 AM, Mach Chen wrote:

> Your I-D is great.

Thanks.

>
> I have some comments and questions.
>
> 1.Section 4.1
>
> "C (Check) - 1 bit: when set, this indicates that the performance
>    metric of interest is the PCE's availability."
>
> When this "C bit" present in a PCMonRep messages, whether it  
> indicates the PCE is available? Is it enough to indicate a PCE's  
> availability? Some more detail info may be desirable.
>

Yes, the aim of th

---

From: JP Vasseur <[email-masked]>
Date: Wed, 1 Nov 2006 16:51:45 -0500

Hi Mach,

Thanks.

> availability? Some more detail info may be desirable.

Yes, the aim of this bit is just to check the PCE's liveness. As  
pointed in the ID, other metrics may be collected that will be  
carried in new objects / flags (to be defined).

>
> 2.Section 4.1
> "The monitoring-id-number MUST be incremented each time a new  
> monitoring is sent to a PCE."
>
> Although 32-bit monitoring-id-number is a huge number, it will  
> overflow one day.So, when this happen, how to deal with it? Restart  
> another round or by other means?

Yes the counter will simply roll-over and considering the set of  
values, the probability of overlap is extremely low ... to say the  
least. I'll clarify this.

>
> When a PCMonReq message is sent along with a PCE chain, the  
> monitoring-id-number is always the same or each PCE will regenerate  
> a new one?
>

Yes,

> 3.Section 4.3
>
> What's the meaning of "Variance-processing-time"?
>

This is the mean squared deviation.

> 4.Section 7
> "Reception of a PCMonRep message: upon receiving a PCMonRep message,
>    the PCE processes the request, adds the relevant objects to the
>    PCMonRep message and forwards the PCMonRep message to the upstream
>    requesting PCE or PCC."
> For a specific PCMonReq message, whether all the PCE along with the  
> PCE chain will do the some collection or some of them will do some  
> special collection?

It is requested to gather performance metrics from all PCE along the  
path computation chain. That said, if some of them do not provide the  
requested data, then the I bit of the MONITORING object is set.

JP.

>
>
> Thanks,
>
> Mach
> ----- Original Message -----
> From: JP Vasseur
> To: [email-masked]
> Sent: Friday, October 20, 2006 8:30 PM
> Subject: [Pce] Feed-back on Monitoring ?
>
> Hi,
>
> path computation chain, processing time spent on path computation  
> at each hop (for performance monitoring or troubleshooting, ...).
>
>>    multiple domains (where a domain is referred to as a collection of
>>    network elements within a common sphere of address management  
>> or path
>> Internet-Drafts are also available by anonymois bit is just to check the PCE's liveness. As  
pointed in the ID, other metrics may be collected that will be  
carried in new objects / flags (to be defined).

>
> 2.Section 4.1
> "The monitoring-id-number MUST be incremented each time a new  
> monitoring is sent to a PCE."
>
> Although 32-bit monitoring-id-number is a huge number, it will  
> overflow one day.So, when this happen, how to deal with it? Restart  
> another round or by other means?

Yes the counter will simply roll-over and considering the set of  
values, the probability of overlap is extremely low ... to say the  
least. I'll clarify this.

>
> When a PCMonReq message is sent along with a PCE chain, the  
> monitoring-id-number is always the same or each PCE will regenerate  
> a new one?
>

Yes,

> 3.Section 4.3
>
> What's the meaning of "Variance-processing-time"?
>

This is the mean squared deviation.

> 4.Section 7
> "Reception of a PCMonRep message: upon receiving a PCMonRep message,
>    the PCE processes the request, adds the relevant objects to the
>    PCMonRep message and forwards the PCMonRep message to the upstream
>    requesting PCE or PCC."
> For a specific PCMonReq message, whether all the PCE along with the  
> PCE chain will do the some collection or some of them will do some  
> special collection?

It is requested to gather performance metrics from all PCE along the  
path computation chain. That said, if some of them do not provide the  
requested data, then the I bit of the MONITORING object is set.

JP.

>
>
> Thanks,
>
> Mach
> ----- Original Message -----
> From: JP Vasseur
> To: [email-masked]
> Sent: Friday, October 20, 2006 8:30 PM
> Subject: [Pce] Feed-back on Monitoring ?
>
> Hi,
>
> path computation chain, processing time spent on path computation  
> at each hop (for performance monitoring or troubleshooting, ...).
>
>>    multiple domains (where a domain is referred to as a collection of
>>    network elements within a common sphere of address management  
>> or path
>> a MIME-compliant mail reader.  Different MIME-compliant mail readers