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 > > 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. > 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. 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] > > >> 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
