Hi,
On Mar 19, 2007, at 4:54 PM, Yuichi Ikejiri wrote:
Hello,
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Yuichi Ikejiri" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2007 11:43 PM
Subject: Re: [Pce] Re: I-D ACTION:draft-vasseur-pce-monitoring-02.txt
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
The PCC does not have to know ! If the PCE chain is limited to a
single element
the monitoring request will figure this out.
now, assume that the PCC received an answer from the
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.
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.
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
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.
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.
Thanks,
Yuichi
thanks,
-d.
"Yuichi Ikejiri" <[EMAIL PROTECTED]>
19/03/2007 14:16
To: [EMAIL PROTECTED]
cc:
Subject: Re: [Pce] Re: I-D
ACTION:draft-vasseur-pce-monitoring-02.txt
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
----- 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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
