Subject: RE : [Pce] PCE Discovery Requirements

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sat, 26 Feb 2005 13:18:42 +0100

Hi Zhang,
 
Please see inline,

-----Message d'origine-----
De : zrh [mailto:[email-masked]] 
Envoyé : vendredi 25 février 2005 08:28
À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
Objet : Re: [Pce] PCE Discovery Requirements

Dear J. Le Roux,
I have been looking in detail at draft-leroux-pce-discovery-reqs-00.txt,and I have some questions and comments.I'd really appreciate it if
 you could spare the time to look at both these points.
 
1)In section 5.2,the last PCE computation capabilities to be advertised is "The PCE capacity in terms of computation power", for the reasion of weighted load balancing of requests in case PCEs do not have the same capacity.
 
I think this is not enough, before PCC sends a request to PCE for a path compution,PCC should also know if the PCE is busy, how busy(maybe the PCE has many path compution requests from another PCCs which have not reply for some reason even if the PCE have pawerful CPU).
To reasonably distribute PCCs's computation requests to PCEs ,PCCs should know the current status of all PCEs's CPU. so I think the status of PCE's CPU(or number of requests which have not been replied, etc) can be included in the hello packet sent by PCE,maybe such hello packet is needed.
[JLLR] 
Actually, advertising CPU status, would require very frequent advertisements to be meaningful. As mentionned by Adrian, a PCE CPU status may change highly frequently. 
For instance let's assume 10 path computations served per second with 50ms per path computation.
This would lead to 20 advertisements per second...
An alternative could rely on a periodic advertisement of the average CPU load, but this may actually not be really relevant.

2)In section 5.3,the backup PCEs are discussed,the location of backup PCE is advertised by PCE.
 
I don't think location of backup PCE can be decided by PCE .
Each PCE may has different abilities for path compution,so PCC may select different PCE to send request for different request,backup PCE  is also not fixed.In other words,the selection of PCE and buckup PCE are also relevant to the computation requests,and are not fixed because of the different requirement of computation.
[JLLR] Yes but assuming that PCE and backup PCE have the same capabilities this may ease backup selection procedure.
Note that this is not a MUST but a SHOULD requirement.
But I agree that this point requires more discussions...
 
3)In section 5.5 third paragraph"The delay for such detection MUST be beyond 60s"
Maybe a "not" is needed.
[JLLR] 
Yes  this is of course a "not",
 
Thanks a lot, Zhang, for these useful comments.
 
Best Regards
 
JL 
 
Thanks,
Zhang

----- Original Message ----- 
From: LE ROUX Jean-Louis  <mailto:[email-masked]> RD-CORE-LAN 
To: [email-masked] 
Sent: Friday, February 25, 2005 2:03 AM
Subject: [Pce] PCE Discovery Requirements

Hi all, 

Here is a requirements ID for automatic PCE discovery. 

Your comments on this draft would be highly welcome. 

Best Regards, 

JL 

A New Internet-Draft is available from the on-line Internet-Drafts directories. 

        Title           : Requirements for Path Computation Element (PCE) Discovery 
        Author(s)       : J. Le Roux, et al. 
        Filename        : draft-leroux-pce-discovery-reqs-00.txt 
        Pages           : 10 
        Date            : 2005-2-14 
        
This document presents a set of requirements for a Path Computation 
   Element (PCE) discovery mechanism that would allow a Path Computation 
   Client (PCC) to discover dynamically and automatically a set of PCEs 
   along with their capabilities. It is intended that solutions that 
   specify procedures and protocol extensions for such PCE discovery 
   satisfy these requirements. 

A URL for this Internet-Draft is: 
 <http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt> http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt 

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit  <https://www1.ietf.org/mailman/listinfo/I-D-announce> 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-leroux-pce-discovery-reqs-00.txt". 

A list of Internet-Drafts directories can be found in 
 <http://www.ietf.org/shadow.html> http://www.ietf.org/shadow.html 
or  <ftp://ftp.ietf.org/ietf/1shadow-sites.txt> ftp://ftp.ietf.org/ietf/1shadow-sites.txt 

Internet-Drafts can also be obtained by e-mail. 

Send a message to: 
        mailserv at ietf.org. 
In the body type: 
        "FILE /internet-drafts/draft-leroux-pce-discovery-reqs-00.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://ftp.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt> ftp://ftp.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-00.txt> 
_______________________________________________ 
I-D-Announce mailing list 
I-D-Announce at ietf.org 
 <https://www1.ietf.org/mailman/listinfo/i-d-announce> https://www1.ietf.org/mailman/listinfo/i-d-announce 

  _____  

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sat, 26 Feb 2005 13:30:55 +0100

Hi Adrian, all

Some inlined comments

>De : Adrian Farrel [mailto:[email-masked]] 
>Envoyé : vendredi 25 février 2005 13:12
>À : zrh; LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]
>Thanks for your comments.
>
>> 1)In section 5.2,the last PCE computation capabilities to be 
>> advertised
>is "The PCE capacity in terms of computation power", for the 
>reasion of weighted load balancing of requests in case PCEs do 
>not have the same capacity.
>>
>> I think this is not enough, before PCC sends a request to PCE for a 
>> path
>compution,PCC should also know if the PCE is busy, how 
>busy(maybe the PCE has many path compution requests from 
>another PCCs which have not reply for some reason even if the 
>PCE have pawerful CPU).
>> To reasonably distribute PCCs's computation requests to PCEs ,PCCs
>should know the current status of all PCEs's CPU. so I think 
>the status of PCE's CPU(or number of requests which have not 
>been replied, etc) can be included in the hello packet sent by 
>PCE,maybe such hello packet is needed.
>
>On the face of it, this is a reasonable requirement. As you 
>say, the PCC would ideally select the least busy PCE to 
>perform its computation for it.
>
>We need to be careful to separate this requirement from how it 
>might be satisfied. So discussion of hello packets snet by PCE 
>should be avoided at this stage. 

Definitely,

>This is probably important 
>because the use of a hello packet might not be a good way of 
>satisfying this requirement - the computation time for a 
>single PCE request is likely to be no more than a few hundred 
>milliseconds and we would certainly need to think hard before 
>asking that each PCE sends a new status message to every PCC 
>in the network every hundred milliseconds.

Yes, and actually such CPU load advertisement could become quite CPU consuming!

>
>I have a concern however. Suppose you had a network with two 
>PCEs and a lot of active PCCs. In the event that one PCE was 
>slightly more busy than the other, all of the PCCs would send 
>their requests to the other PCE causing immediate congestion.
>
>So here is a suggestion. Suppose instead of measuring queue 
>size and CPU capacity we simply allow a PCE to report its 
>status as "congested" if it deems that it is too busy. PCEs 
>may still continue to send requests to a congested PCE, but 
>may use this information to prefer a different PCE.
>
>The congested flag can be set and flooded instantly the PCE 
>believes that it is congested, and only releases under a 
>threshold and on a normal discovery refresh.

Yes, this could be a relevant approach, with a kind of hysterisis mechanism to avoid congestion oscillations.

Note that a pretty similar mechanism is defined in draft-leroux-ccamp-ctrl-saturation-00
to address LSR congestions.

>Each PCE 
>> may has different abilities for path compution,so PCC may
>select different PCE to send request for different 
>request,backup PCE  is also not fixed.In other words,the 
>selection of PCE and buckup PCE are also relevant to the 
>computation requests,and are not fixed because of the 
>different requirement of computation.
>
>Well, a PCE *might* know that it has a partner that matches 
>(or betters) its capabilities and which acts as its backup. In 
>this case, why should it not advertise this information?

I agree with you, such information may help backup PCE selection procedure.
Moreover note that this is not a MUST requirement.

>Indeed.

Sure, will be fixed in next revision.

Thanks for these useful commments.

Regards,

JL

>Adrian