JP, All,

Here are a few comments on the PCEP I-D.

General comments:

1. Nice job, good technical solution, quite complete for a first draft.

2. So far we only have PCE Communication Protocol Generic Requirements

http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req

s-00.txt, although we expect application-specific requirements as

specified in Section 6.1.9 of that document.  How do we know that the

proposed PCEP satisfies the application-specific requirements when we

have no such requirements at this point?  Don't we need some of the

application-specific requirements first, such as:

- intra-area path computation

- inter-area path computation

- inter-AS intra provider and inter-AS inter-provider path computation?

3. You list requirements that are satisfied in Section 5.  It would be

good to identify in general how the proposed PCEP satisfies all the

requirements in

http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req

s-00.txt. 

In particular, it is not entirely clear how/where the

following requirements are addressed in the PCEP I-D: 6.1.4,

6.1.6 -->

6.1.10, 6.2.1 --> 6.2.3, 6.3.3.

4. You mention that PCEP is extensible, but it isn't clear how this

extensibility would be accomplished.  For example, in Section 7.2, RE

'format of a PCReq message', how do we extend the list of attributes in

case other attributes in the PCReq message need to be added in the

future?  Same comment on PCRep message in Section 7.3, etc.

Specific comments:

1. Section 5, last line: 'regular PCE' and 'PCE itself acting as a PCC'

are not terms used in [PCE-ARCH].  For instance, the latter is defined

as a 'composite PCE' in [PCE-ARCH].  It would be best to use terminology

consistent with [PCE-ARCH].

2. Section 6: I agree with Dean Cheng that open, close, and hello are

not needed, and that detailed capability discovery is needed upon PCEP

connection setup.

3. Section 8.2, RE 'P (Partial)':  We define 'explicit PCE path' and

'strict/loose PCE path' in [PCE-ARCH], rather than 'Partial'.  Again,

consistent terminology would be good.

4. Section 8.4: Is 'Bandwidth' the only traffic descriptor allowed?

What if other descriptors (e.g., token bucket) are desired, how are

these going to be included if needed in the future?

5. Section 8.5: What if 'path jitter', 'path bit error rate', and other

path QoS parameters, in addition to 'path delay', are desired?  How are

these going to be included if needed in the future?

6. Section 8.7, line 1: 'Section 8' --> 'Section 9'

7. Section 8.8, RE 'An implementation may decide to cancel such

notification if the PCC is in down state for a specific period. A

RECOMMENDED value for such delay is 1 hour.'  What is the 1-hour

recommendation based on, sounds pretty arbitrary?

8. Section 16.2: Why are [PCE-ARCH] and [PCE-GEN-COM-REQ] informative

references, shouldn't these be normative references?

Thanks,

Regards,

Jerry

-----Original Message-----

From: pce-bounces <at> lists.ietf.org [mailto:pce-bounces <at> lists.ietf.org] On

Behalf Of JP Vasseur

Sent: Thursday, May 26, 2005 11:42 AM

To: pce <at> ietf.org

Subject: [Pce] WG feed-backs on PCEP

Dear WG,

A new ID has recently been posted 

(http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) 

proposing a new PCE communication protocol. There are several aspects 

for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to 

get your feed-backs (see section 6). Comments are also very welcome on 

the other parts of the ID of course.

Thanks.

JP.