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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Sat, 16 Jul 2005 19:09:02 -0500

Hi Dimitri,

Thanks a lot for your review and comments.

> 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 responsiveness (in particular when a 
> sequence of PCEs is involved) and maintenance?

Agree, requirements on responsiveness would be good, but may be
difficult to quantify in general (especially with multiple PCE
computations).

Not sure what requirements you are suggesting for 'maintenance', as
related to PCEP?  Maintenance of what?

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

Not sure what point you're referring to here RE the discovery process?
 
> what the "association" means here?

Right, needs to be stated more precisely.

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

No, especially in the multiple PCE path computation model (see Sections
6.3 and 6.4 of the PCE architecture document
http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-00.txt).
I see your point, needs to be clarified.

> - what about PCE 
> hosting uncomplete topological information of e.g. 
> peripherical networks 

Right, this is a typical case IMO.

> 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

Correct, there is not much detail or specifics on 'throttling of
requests', just a requirement to be able to throttle messages.  What
detail do you suggest for this requirement?
 
> 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?

It is not a SHALL requirement for the PCE to update the PCC in an
unsolicited manner, just a required capability.
 
> 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

Agreed it would be good to plug in 'boundary' numbers here to quantify
scalability.  However, I'm skeptical that can agree on the right
numbers, but one can try :-)
 
> 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

Agreed, we need to be sensitive to (too much) feature creep.

Thanks,
Regards,
Jerry

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 17 Jul 2005 13:39:53 +0200

hi jerry - see in-line for some clarifications:

> related to PCEP?  Maintenance of what?

maintenance of the relationship between PCEs, if such mechanism is not 
in place the "local" PCE may receive request that it can not further 
send to other peering PCE(s) while during the time the local PCE 
discovers its peering PCE(s) are down such amount of request may be 
quite high - in brief, the "local PCE" should minimize the number of 
incoming request it can not (temporarily) process otherwise -

note: the term "limited" in the above paragraph does not tell if a PCC 
sends multiple requests to the PCE  whether these are making use of the 
same "transport" connection or whether a new one is established for each 
request

> Not sure what point you're referring to here RE the discovery process?

yes - in part. section 6.4 and 6.5 of the discovery document

> numbers, but one can try :-)

yes - this is what i would suggest as this work is driven by the user 
community i hope one could come with a representative sample

> Agreed, we need to be sensitive to (too much) feature creep.

this is also the approach i would make use of i.e. a less featured PCE 
but more robust protocol construction - at least in a first phase -

thanks,
- dimitri.

> .