Subject: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt

From: [email-masked]
Date: Fri, 2 Mar 2007 16:20:51 +0100

a simple question

the document repeats twice that it critical to monitor the state of 
the PC chain (see below)

i try to understand reasoning - can authors clarify ?

for perf.mon ? is the PCC going to tack perfs of PC servers ?

for troubleshooting ? but for which trouble ? (this said, i am also
concerned by the fact that if each PCC for each path across a set of
PCEs starts to generate such state monitoring then for sure servers
may experience overload)

due to limited visibility ? why is this requiring "state monitoring" ?

---> in brief, i still believe a serious problem statement shall be
brought up before jumping in the specification of objects (the bits
of the wire)

thanks,
-d.
--

"In PCE-based environments, it is critical to monitor the state of the
   path computation chain that can be used for performance monitoring
   and troubleshooting purposes.  This document specifies procedures and
   extensions to the Path Computation Element Protocol (PCEP)
   ([I-D.ietf-pce-pcep]) in order to monitor the path computation chain
   and gather various performance metrics.

   As discussed in [RFC4655], a TE LSP may be computed by one PCE
   (referred to as single PCE path computation) or several PCEs
   (referred to as multiple PCE path computation).  In the former case,
   the PCC may be able to use IGP extensions to check the liveness of
   the PCE (see [I-D.ietf-pce-disco-proto-ospf] and
   [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages.
   In contrast, when multiple PCEs are involved in the path computation
   chain an example of which is the BRPC procedure defined in
   [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the first
   PCE involved in the path computation chain.  Thus, it is critical to
   define mechanisms in order to monitor the state of the path
   computation chain."

--

[email-masked]
01/03/2007 21:50
Please respond to internet-drafts
 
        To:     [email-masked]
        cc: 
        Subject:        I-D ACTION:draft-vasseur-pce-monitoring-02.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. Le Roux, J. Vasseur
                 Filename                : 
draft-vasseur-pce-monitoring-02.txt
                 Pages                           : 18
                 Date                            : 2007-3-1
 
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 PCE-based environments it is thus critical to monitor
   the state of the path computation chain 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-02.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-02.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-02.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.
ftp://[email-masked]/internet-drafts/draft-vasseur-pce-monitoring-02.txt
_______________________________________________
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: JP Vasseur <[email-masked]>
Date: Fri, 2 Mar 2007 11:03:45 -0500

Hi Dimitri,

> the document repeats twice that it critical to monitor the state of

Yes indeed.

> for troubleshooting ? but for which trouble ?

I think that the motivation is fairly simple here ... You may want to  
monitor various aspects.
For example, you may want to measure the path computation response  
time. That might be
for performance monitoring or troubleshooting because a PCC  
experience very long response
time. The motivation sounds extremely obvious: PCE OAM. As for any  
other system, the user
may want to monitor the performance for network design,  
troubleshooting, ...

> (this said, i am also

Ah no ... this is an implementation issue on the PCE if you've such  
issue.
Furthermore, if you experience an issue, would you prefer to ignore  
it or
to be able to locate it ?

> brought up before jumping in the specification of objects (the bits

Hope this clarifies but the motivations are indeed quite  
straightforward.

Thanks.

JP.

---

From: [email-masked]
Date: Fri, 2 Mar 2007 17:50:08 +0100

hi j-p

see in-line

JP Vasseur <[email-masked]>
02/03/2007 17:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        Subject:        Re: [Pce] Re: I-D 
ACTION:draft-vasseur-pce-monitoring-02.txt

Hi Dimitri,

Yes indeed.

[dp] PC response time, but how are you going to ensure that running
conditions are identical at time t[n-1], t[n], t[n+1] ? in fact the
question is the relevance of repeating a given request when the run
conditions can be completely different

[dp] i disagree, if one builds a PCE to sustain x PC demands per unit
of time, but PCE gets now confronted to the fact that a number X of
clients, X >> x, are permanently polling the server (remember that
the PC server can be memoryless) for monitoring all the previously 
computed path, the running conditions are completely different, in
fact the performance of your system degrades over time (i know a well
known operating system that shows the same property ;-(

=> the PCE OAM mechanism implies a completely mode of operation that 
influence the capacity of the system

Furthermore, if you experience an issue, would you prefer to ignore 
it or to be able to locate it ?

[dp] use my local computation capability rely on "external domain"
to solve an local problem may be 

[dp] unfortunately, i am not convinced about the usefulness of this
mechanism and the problem is that if it would harmless then i would
not have any issue but it is not

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 5 Mar 2007 16:36:27 -0500

Hi Dimitri,

> JP Vasseur <[email-masked]>

You may not be able to capture a transient issue but this is similar  
to the
issue of a packet experiencing a transient congestion: you do a  
traceroute and when
the packet is processed the issue might have disappeared. Still, it  
is useful to have
the tool the determine a bootleneck that sustains. Furthermore you  
get the average/max
and potentially other metrics of interest that relate to a past event.

> known operating system that shows the same property ;-(

Not sure what you refer to.

But let me re-explain: Indeed the PCC may start to send many such
monitoring requests but here is my first point: you PCC must make sure
to act diligently here. Using the same analogy as before you could send
thousands of ping to a congested host ... bad idea of course.  
Moreover your
PCE scheduler should smartly handle various requests types. It it gets
congested there are many ways to avoid more congestion and thus to  
impact
the actual path computation requests because of monitoring requests.

> to solve an local problem may be

?

> not have any issue but it is not

Hope that I shed some light.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Sun, 18 Mar 2007 20:57:43 +0100

FYI, look at my reply to this email.

More in line,

On Mar 18, 2007, at 5:48 PM, DOLGANOW Andrew wrote:

> Please see below prefixed with [ad]
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]
>> Sent: Friday, March 02, 2007 11:50 AM
>> To: JP Vasseur
>> Cc: [email-masked]
>> Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt
>>
>> hi j-p
>>
>> see in-line
>>
>>
>>
>>
>> I think that the motivation is fairly simple here ... You may
>> want to monitor various aspects.
>> For example, you may want to measure the path computation
>> response time. That might be for performance monitoring or
>> troubleshooting because a PCC experience very long response
>> time. The motivation sounds extremely obvious: PCE OAM. As
>> for any other system, the user may want to monitor the
>> performance for network design, troubleshooting, ...
>>
>> [dp] PC response time, but how are you going to ensure that
>> running conditions are identical at time t[n-1], t[n], t[n+1]
>> ? in fact the question is the relevance of repeating a given
>> request when the run conditions can be completely different
>>
> [ad] Dimitri brings a valid point here. This was discussed in San  
> Diego,
> proposed to be taken to the list and never really answered. In  
> addition
> to the time variable, for performance monitoring to work, we would  
> need
> to ensure that no steps are skipped along the process. The best way I
> would say would be to monitor Request/Results from PCC and if required
> issue another PC request (which could collect timestamps along the
> process).

You miss a point here ... of course, you can monitor the overall  
response time
but how do you figure out the time you spent along the PCE chain ?

>> Ah no ... this is an implementation issue on the PCE if
>> you've such issue.
>>
>> [dp] i disagree, if one builds a PCE to sustain x PC demands
>> per unit of time, but PCE gets now confronted to the fact
>> that a number X of clients, X >> x, are permanently polling
>> the server (remember that the PC server can be memoryless)
>> for monitoring all the previously computed path, the running
>> conditions are completely different, in fact the performance
>> of your system degrades over time (i know a well known
>> operating system that shows the same property ;-(
>>
>
> [ad] Agree with Dimitri.

Please look at my reply to Dimitri to this point.

> More so, PCE may be implemented to give
> priority to various messages and limit certain messages (so the
> implementation may not help monitoring here as JP is suggesting) and
> again you could get different results of a monitoring request than
> computational request.

Again you make some confusion here: we're not trying to build a way to
proritize messages, ... this is already in PCEP. The aim of the this  
draft is
to have OAM.

>
>> => the PCE OAM mechanism implies a completely mode of
>> operation that influence the capacity of the system
>>
>> Furthermore, if you experience an issue, would you prefer to
>> ignore it or to be able to locate it ?
>>
>>> brought up before jumping in the specification of objects
>> (the bits of
>>> the wire)
>>>
>>>
>>
>> [dp] unfortunately, i am not convinced about the usefulness
>> of this mechanism and the problem is that if it would
>> harmless then i would not have any issue but it is not
>>
> [ad] agree with Dimitri, all that is looked after by the monitoring
> mechanism can be achieved without that mechanism in place.

So if you have a PCE chain PCC----PCE1----PCE2-----Dest
How do the determine various perf metric along the chain with the  
mechanism
in place ?

> The mechanism
> may add to the problem by being badly deployed and with many PCCs
> runnning performance monitoring. With scaling and time passing the
> mechanism may degrade PCE.

This is implementation specific. If you design your system properly,  
you won't
have this problem. Back to your previous point you have different  
message priority
+ other mechanisms to avoid this.

> We do not want to monitor the monitoring
> mechanism?
>

Sorry but this makes no sense. We're not monitoring the monitoring  
mechanism at all.

JP.

>>>    and troubleshooting purposes.  This document specifies
>> procedures
>>> and
>>>    PCE involved in the path computation chain.  Thus, it is
>> critical
>>> to
>>>         Subject:        I-D
>>>    network elements within a common sphere of address management or
>>> path computational responsibility such as IGP areas and Autonomous
>>> You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>> logging in, type "cd internet-drafts" and then "get
>>> draft-vasseur-pce-monitoring-02.txt".
>>>
>>> http://www.ietf.org/shadow.html or
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>                  feature, insert the command "ENCODING mime" before
>>> the "FILE"
>>>                  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

---

From: "Yuichi Ikejiri" <[email-masked]>
Date: Mon, 19 Mar 2007 22:16:28 +0900

Hi,

>From perspective of service provider, this kind of monitoring or diagnostics
tool described in this draft is very useful and indespendable in the network
where PCE chain is used (like the network devided into multiple IGP areas
and ABRs are working as PCEs) .

When a PCC doesn't receive any response from a peer PCE, (meaning that
a requested path is not established for a while), an operator would try to
check
not only the peer PCE, but also the PCE chain to see if the PCE chain is
working or appropriate, and who does not response the result or takes
very long time to do path calculation. We need to have a mechanism to do
such check.

The chain itself is different depending on the END-POINTS or other
contraints,
so that this kind of monitoring should be reqeusted with the PCReq message.
And
also an operator sometimes wants to check only PCE chain itself without any
actual path
computation and sometimes wants to check the actual processing time at a PCE
in the PCE chain with actual path computation.

This is just an example of the situation, coming up in my mind, where SPs
may use
the tools described in this draft. I believe that the example(use case) I
mentioned,
is covered in the draft by choosing appropriate objects proposed.
#if no, please clarify, authors.

So, I think that this kind of monitoring tool is needed.

Thanks,
Yuichi

---

From: [email-masked]
Date: Mon, 19 Mar 2007 15:43:46 +0100

hello 

just a question to see whether i understand the point -

if the PCC doesn't receive an answer from the PCE after 
initiating a request how does the PCC knows there is a
chain of PCE behind the PCE towards which the request
has been initiated - in brief what is the purpose of 
having a monitoring when the PCE is an on-path techno

now, assume that the PCC received an answer from the 
PCE is there a need keep track of PCE chain liveness ?

i have also trouble to understanding the following:

"When a PCC doesn't receive any response from a peer PCE, (meaning that
a requested path is not established for a while)"

PCE do not establish "path" they compute paths

thanks,
-d.

"Yuichi Ikejiri" <[email-masked]>
19/03/2007 14:16
 
        To:     [email-masked]
        cc: 

Hi,

>From perspective of service provider, this kind of monitoring or 
diagnostics
tool described in this draft is very useful and indespendable in the 
network
where PCE chain is used (like the network devided into multiple IGP areas
and ABRs are working as PCEs) .

The chain itself is different depending on the END-POINTS or other
contraints,
so that this kind of monitoring should be reqeusted with the PCReq 
message.
And
also an operator sometimes wants to check only PCE chain itself without 
any
actual path
computation and sometimes wants to check the actual processing time at a 
PCE
in the PCE chain with actual path computation.

Thanks,
Yuichi

---

From: "Yuichi Ikejiri" <[email-masked]>
Date: Tue, 20 Mar 2007 00:54:37 +0900

Hello,

----- Original Message ----- 
From: <[email-masked]>
To: "Yuichi Ikejiri" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 19, 2007 11:43 PM
Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt

> PCE is there a need keep track of PCE chain liveness ?
It depends on the situation, but I think not keep track of the chain
so often in the example I described. Just several times to see
what is happening in the current chain with the specific path
requests. But maybe there is also a case where longer monitoring
is needed in periodic manner. Again it depends on the situation
where the tool is used, I think.

> PCE do not establish "path" they compute paths
I know that. I am sorry for the confusion. I just described what an operator
actually knows as a result of that the PCC does not receive any path
calculation
result from the PCE in the actual network operation. But it was not good
example,
 so just ignore the text enclosed in the parenthesis.

Thanks,
Yuichi

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Mar 2007 06:17:19 +0100

Hi Yuichi,

Thanks for the useful feed-back. See in line.

On Mar 19, 2007, at 2:16 PM, Yuichi Ikejiri wrote:

> When a PCC doesn't receive any response from a peer PCE, From [email-masked] Tue Mar 20 01:34:04 2007
From: JP Vasseur <[email-masked]>
Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt
Date: Tue, 20 Mar 2007 06:17:19 +0100
To: Yuichi Ikejiri <[email-masked]>
Cc: [email-masked]

Hi Yuichi,

Thanks for the useful feed-back. See in line.

> very long time to do path calculation. We need to have a mechanism  

That is indeed for the one main features of this document.

> in the PCE chain with actual path computation.

Indeed: this is why we introduced the ability to check the PCE chain  
in the context of a
specific path computation or to retrieve various metrics related to  
set of path computations
performed over a period of time (specific/general).

> #if no, please clarify, authors.

This is exactly what we propose.

Thanks.

JP.

>>> to ensure that no steps are skipped along the process. The b(meaning that

That is indeed for the one main features of this document.

> in the PCE chain with actual path computation.

Indeed: this is why we introduced the ability to check the PCE chain  
in the context of a
specific path computation or to retrieve various metrics related to  
set of path computations
performed over a period of time (specific/general).

> #if no, please clarify, authors.

This is exactly what we propose.

Thanks.

JP.

>>>>>    As discussed in [RFC4655]est  
>>> way I
>>>>>             , a TE LSP may be computed by one PCE

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Mar 2007 06:23:04 +0100

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Mar 2007 06:23:04 +0100

Hi,

>> having a monitoring when the PCE is an on-path techno

The PCC does not have to know ! If the PCE chain is limited to a  
single element
the monitoring request will figure this out.

> where the tool is used, I think.

You're right. As with many other OAM tools, the goal is not to keep  
sending probes in
the network but to use the tool as needed, which can be automatically  
or manually
triggered in various circumstances.

>  so just ignore the text enclosed in the parenthesis.

The example is actually quite good and typical: such OAM tool can be  
used to determine
a potential bottleneck along a PCE chain or should the PCE chain be  
broken to spot the
PCE that does not respond, which may not be possible using the IGP  
discovery depending
on the location of such PCE.

Thanks.

JP.

>> a requested path is not establish=20Re=3A=20I-D=20ACTION=3Adraft-vasseur-pce-moni
	toring-02.txt |Sender:=20;
	bh=vYsbrpERqoXGF1pjr48YYn+w2DQorRtKSB9TiIHGFxw=;
	b=eKlIyniGuy+871GV78N/A2eFQw/GrXap7AZg1A8jWsv0WdjWQKcIzAfh7BegSkhs/s7eGzKk
	DxVgb+1WnDygAlddRVLXd02SFKN1YK+ioRk7oi3sYLLLTEpiLQUQBCMS;
Cc: [email-masked]

Hi,

>> having a monitoring when the PCE is an on-path techno

The PCC does not have to know ! If the PCE chain is limited to a  
single element
the monitoring request will figure this out.

> where the tool is used, I think.

You're right. As with many other OAM tools, the goal is not to keep  
sending probes in
the network but to use the tool as needed, which can be automatically  
or manually
triggered in various circumstances.

>  so just ignore the text enclosed in the parenthesis.

The example is actually quite good and typical: such OAM tool can be  
used to determine
a potential bottleneck along a PCE chain or should the PCE chain be  
broken to spot the
PCE that does not respond, which may not be possible using the IGP  
discovery depending
on the location of such PCE.

Thanks.

JP.

>>> response timed for a while), an operator  
>> would try to
>> check
>>>>>>    (referred to as multiple e
>>>>>>    [I-D.ietf-pce-brpc], the PCC's visibility may be limited to  
>>>>>> the
>>>>>> first
>>>>>>           PCE path computation).  In the former
>>>>>> case,
>>>>>>    [I-D.ietf-pce-brpc], the PCC's visibility may be limited to  
>>>>>> the
>>>>>> first