Hi Dimitri,
On Mar 2, 2007, at 11:50 AM, [EMAIL PROTECTED]
wrote:
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]
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
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.
(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 ;-(
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.
=> 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
Hope that I shed some light.
Thanks.
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
