Hi Yuichi,
Thanks for the useful feed-back. See in line.
On Mar 19, 2007, at 2:16 PM, Yuichi Ikejiri wrote:
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.
That is indeed for the one main features of this document.
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.
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).
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.
This is exactly what we propose.
So, I think that this kind of monitoring tool is needed.
Thanks.
JP.
Thanks,
Yuichi
----- Original Message -----
From: "JP Vasseur" <[EMAIL PROTECTED]>
To: "DOLGANOW Andrew" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2007 4:57 AM
Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt
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 PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Friday, March 02, 2007 11:50 AM
To: JP Vasseur
Cc: [EMAIL PROTECTED]
Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-
monitoring-02.txt
hi j-p
see in-line
JP Vasseur <[EMAIL PROTECTED]>
02/03/2007 17:03
To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: [Pce] Re: I-D
ACTION:draft-vasseur-pce-monitoring-02.txt
Hi Dimitri,
On Mar 2, 2007, at 10:20 AM, [EMAIL PROTECTED]
lucent.be
wrote:
a simple question
the document repeats twice that it critical to monitor the
state of
the PC chain (see below)
Yes indeed.
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 ?
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 ?
(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)
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 ?
[dp] use my local computation capability rely on "external domain"
to solve an local problem may be
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)
Hope this clarifies but the motivations are indeed quite
straightforward.
[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.
Thanks.
JP.
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 PROTECTED]
01/03/2007 21:50
Please respond to internet-drafts
To: [email protected]
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 PROTECTED] 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 PROTECTED]
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 PROTECTED]/internet-drafts/draft-vasseur-pce-
monitoring-02.txt
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
