Subject: RE: [Pce] WG feed-backs on PCEP

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 6 Jun 2005 14:11:02 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur
Sent: Thursday, May 26, 2005 11:42 AM
To: [email-masked]
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.

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

---

From: JP Vasseur <[email-masked]>
Date: Wed, 8 Jun 2005 11:06:44 -0400

Hi Jerry,

First of all thanks for your comments. See in line,

Thanks.

> - inter-AS intra provider and inter-AS inter-provider path  

Well as with any protocol, we will first start with the basics and  
extend it to meet further requirements. This is why we made PCEP as  
extensible as possible by offering the ability to quite easily add  
messages and objects in the future without compromising the protocol  
infrastructure. The aim of this first version is to cover the  
protocol basics and extensions might be added in the future to meet  
application-specific requirements.

> s-00.txt.

"The PCE Working Group has produced a set of requirements for the PCE  
communication protocols ([PCE-COM-GEN-REQ]) which served as input to  
the design of the PCEP protocol "

> In particular, it is not entirely clear how/where the
> following requirements are addressed in the PCEP I-D: 6.1.4,

You're absolutely right and a detailed "Security" section must be  
added to the PCEP draft. Will be done in the next revision.

> 6.1.6 -->

I think that there are various requirements that are satisfied.  
Trying to analyze them one by one is a good idea. To avoid a quite  
long email, may I suggest to have separate emails (one per item) ?

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

That really depends on the attribute ... could be as simple as a new  
flag in the REQUEST-ID object or require an entirely new object  
carried in both the PCReq and PCRep messages.

> consistent with [PCE-ARCH].

Good point ! Will fix that.

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

ok thanks for the feed-back.

> consistent terminology would be good.

Also agree.

> these going to be included if needed in the future?

As simple as new objects. I think that we will likely see new such  
object in the future, but let's start with the required minimum.

> these going to be included if needed in the future?

Well we may either decide to:
- Have a single object with all such attributes
- Have multiple object

This will be discussed once such requirements will be known.

Thanks.

> recommendation based on, sounds pretty arbitrary?

Yes indeed ... from the time the ID potentially moves forward we  
should have implementations providing a better idea of the suggested  
value.

Thanks.

JP.