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
> (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 ;-(
=> 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
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
