Subject: Re: [Pce] PCE Discovery Requirements

From: JP Vasseur <[email-masked]>
Date: Wed, 2 Mar 2005 16:09:51 -0500

Hi,

On Feb 25, 2005, at 7:11 AM, Adrian Farrel wrote:

> Hi Zhang,
>
> 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. 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.
>
> 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.

a few comments:
- PCE resource availability could be announced by various means indeed. 
Potential oscillations could be avoided by implementing an appropriate 
resource availability estimation algorithm on the PCE itself and/or an 
appropriate PCE selection algorithms on PCCs. Note that both mechanisms 
would be implementation dependent and may not require to the 
standardized.
- I agree with Adrian that focus must be given to the requirements here 
rather than the solution which will be discussed right after. For the 
sake of illustration, IGP/BGP but also the PCC/PCE communication 
protocol could be used for example to explicitly notify of a congested 
state so as to provoke a path computation request reroute to another 
PCE (that said, even in this case, this requires oscillation prevention 
mechanisms, ...).

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

Furthermore, a carrier may decide to configure a PCE to act a backup 
only.

Thanks.

JP.

>
>> 3)In section 5.5 third paragraph"The delay for such detection MUST be
> beyond 60s"
>> Maybe a "not" is needed.
>
> Indeed.
>
> Thanks,
> Adrian
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
>

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