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, ...
(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.
Furthermore, if you experience an issue, would you prefer to ignore
it or
to be able to locate it ?
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.
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
