Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt

From: [email-masked]
Date: Fri, 15 Jul 2005 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element Working Group of the IETF.

	Title		: PCE Communication Protocol Generic Requirements
	Author(s)	: J. Le Roux, J. Ash
	Filename	: draft-ietf-pce-comm-protocol-gen-reqs-01.txt
	Pages		: 19
	Date		: 2005-7-15
	
The PCE model is described in the "PCE Architecture" document and
   facilitates path computation requests from Path Computation Clients
   (PCCs) to Path Computation Elements (PCEs).  This document specifies
   generic requirements for a communication protocol between PCCs and
   PCEs, and also between PCEs where cooperation between PCEs is
   desirable.  Subsequent documents will specify application-specific
   requirements for the PCE communication protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-ietf-pce-comm-protocol-gen-reqs-01.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-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-01.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.
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 15 Jul 2005 17:13:24 -0500

Hi All,

Please review and comment on "PCE Communication Protocol Generic
Requirements"
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-01.txt

The update incorporates comments on the list and Adrian's very thorough
review for the DT -- the main changes are as follows:

1. significant (but mostly editorial) updates to Section 6 'PCEP Generic
Requirements',
2. added requirements summary at beginning of Section 6,
3. added requirement on path reoptimization to Section 6.1.4 'Path
Computation Requests', 
4. added requirement for 'less constrained paths' in Section 6.1.4 (Path
Computation Requests) and 6.1.5 (Path Computation Responses), as
suggested by JP in
http://www1.ietf.org/mail-archive/web/pce/current/msg00254.html,
5. added Section 6.1.16 'Constraints'.

Open Issues:

1. Regarding item #4 on 'less constrained paths', there were several
expressions of support for this requirement from SP's, however, there
were countering views from Eric Gray
http://www1.ietf.org/mail-archive/web/pce/current/msg00256.html and
Adrian http://www1.ietf.org/mail-archive/web/pce/current/msg00268.html.
Please review and offer your comments/suggestions.

Please review and comment on the I-D.  

Thanks,
Regards,
Jerry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, July 15, 2005 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Path Computation Element Working Group
of the IETF.

	Title		: PCE Communication Protocol Generic
Requirements
	Author(s)	: J. Le Roux, J. Ash
	Filename	: draft-ietf-pce-comm-protocol-gen-reqs-01.txt
	Pages		: 19
	Date		: 2005-7-15

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-01.txt

---

From: [email-masked]
Date: Sat, 16 Jul 2005 12:28:40 +0200

hi jerry, authors

thanks for the update - i have several comments:

section 6.1.2

" There is no requirement to maintain a session or association between
communicating PCC and PCE, nor between communicating PCEs. The
request/response exchange defines a limited association between
requester and responder."

ok but this is the resulting requirement what about requirements in terms of responsivness (in particular when a sequence of PCEs is involved) and maintenance ? also there is a too high expectation in terms of what the discovery process will deliver here - this point has already been discussed on this list -

what the "association" means here ?

section 6.1.4

" The request message MUST include, at least, a source and a
destination. "

it seems to me this is not the only requirement one has to deal with as there is an implicit assumption that the receiving PCE as full vision of the source/dest domain topology - is that a safe assumption ? - what about PCE hosting uncomplete topological information of e.g. peripherical networks

section 6.1.8

" - Flow control and back-pressure, as specified above with the
throttling of requests."

i am looking above but do not see much details about this requirement, which is the cornerstone for handling overloads

section 6.1.11

why unsolicited notifications shall also cover "updated path" is there a requirement that once computed the PCE shall the PCC updated with new (and unsolicited) computational results ?

section 6.1.15

"The PCEP MUST scale well, at least as good as linearly, with an
increase of any of the following parameters:

- number of PCCs
- number of PCEs
- number of PCCs communicating with a single PCE
- number of PCEs communicated to by a single PCC
- number of PCEs communicated to by another PCE
- number of domains
- number of path requests
- handling bursts of requests."

it would have surprised me someone would have said the system should not be scalable - more indicative is the expectation in terms of number of requests per unit of time (average/min/max) and the number of PCEs involved in the process per request (note that concerning the PCC we have a rough idea about the topologies PCE WG is expected to cover) - this said some indicative boundary numbers could be helpful for the design itself

last point: concerning the open point your are mentioning i have the general feeling that the bar has been put to high in terms of PCE capabilities which at the end somehow makes the achievability of requirement stated in section 6.1.13 difficult