Subject: [Pce] PCE Discovery Requirements

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 24 Feb 2005 19:03:09 +0100

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.t
xt

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 
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 
or 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.t
xt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: zrh <[email-masked]>
Date: Fri, 25 Feb 2005 15:27:30 +0800

PCE Discovery RequirementsDear 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.

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.

3)In section 5.5 third paragraph"The delay for such detection MUST be beyond 60s"
Maybe a "not" is needed.

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

  Hi all, 

  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 

  A URL for this Internet-Draft is: 
  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 
  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". 

  Send a message to: 
          mailserv at ietf.org. 
  In the body type: 
          
          a MIME-compliant mail reader.  Different MIME-compliant mail readers 

  <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 

------------------------------------------------------------------------------

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Feb 2005 12:11:48 -0000

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.

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

> 3)In section 5.5 third paragraph"The delay for such detection MUST be
beyond 60s"

Indeed.

Thanks,
Adrian

---

From: Renhai Zhang <[email-masked]>
Date: Sat, 26 Feb 2005 15:06:53 +0800

Dear Adrian,
 Thanks for your reply.Please see my words in-line.

> it is congested, and only releases under a threshold and on a normal
  Good idea. I think it is the best way to solve PCE's congesttion if such thing exists.

> not advertise this information?
 Right, but I have a doubt: Why does PCE know more such info than PCCs?
 Is there anything defferent between PCE and PCC for discovery of PCE in the discovery mechanism?
 Can we use the  mechanism of selecting DR and BDR in OSPF protocol for reference?

Best regards,
Zhang

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 26 Feb 2005 13:47:20 -0000

Hi again,

[SNIPped to just one issue]

>  Is there anything defferent between PCE and PCC for discovery of PCE in
the
> discovery mechanism? Can we use the  mechanism of selecting DR and BDR
in
> OSPF protocol for reference?

You raise an interesting point: that is, the automatic negotiation of
primary and backup roles for PCEs. We should discuss this further to
determine whether it is functionally useful. If it is, then you have
certainly suggested a probable solution.

But note that in some of the proposed PCE architectures, the number of
PCEs in a domain is relatively small. We might assume, therefore, that the
PCEs are under management control and are sufficiently few that the act of
managing the full set of PCEs is relatively easy. In this case, we might
assume that an operator would designate primary and backup roles for PCEs.

PCE discovery is still needed for PCCs since there are far more of them in
the network.

Regards,
Adrian