Subject: Re: [Pce] Choosing the PCE protocol

From: JP Vasseur <[email-masked]>
Date: Mon, 3 Oct 2005 17:41:22 -0400

Hi,

First of all, we would like to explain a bit further the process that  
we followed to come up with the proposed PCEP protocol:

We started by evaluating existing protocols (such as COPS, HTTP/XML +  
others) to see whether we could meet the PCE requirements by means of  
minor extensions (without negative impact on the protocol).  
Considering the PCE WG's specific requirements, we came to the  
conclusion that a new protocol was required and no existing protocol  
could be naturally and efficiently extended to meet such  
requirements. Furthermore, we did not want to have to use unneeded  
features/functionalities that were present in existing protocols and  
that have been designed for other purposes.

Now to answer Adrian's question:

Thus, we started to work on a new protocol (PCEP) for which we have  
received so far quite a few comments which have been incorporated in  
the latest revision (rev -02). Here are the following PCEP's  
characteristics:
     - Fully meets the PCE requirements spelled out in the PCE  
communication requirement document (draft-ietf-pce-comm-protocol-gen- 
reqs-02.txt) -> this is
     detailed in Appendix A of the draft,
     - Very lightweight protocol w/o complex state machinery,
     - Easily extensible by adding new messages or objects should we  
have to address new requirements in the future,
     - Limited number of messages and objects (actually there are  
several applications that would require the implementation a very  
limited subset of objects)
     - Maximum reuse of mechanisms which have already been defined  
and deployed in other protocols (no need to re-invent the wheel !).
     - Reuse of TCP for transport thus providing reliable messaging,  
flow control, security, ...
     - Support of solicited and unsolicited communication messages
     - ...

Note that implementers have expressed interest in such solution.

Thanks.

JP, Jean-Louis, Eiji, Alia, Arthi and Andrew.

On Sep 29, 2005, at 10:27 AM, Adrian Farrel wrote:

> Hi,
>
> Three candidate protocols have been brought to my attention for us to
> consider. These are (in no specific order):
> - HTTP
> - PCECP (as draft-vasseur-pce-pcep-02.txt)
> - COPS
>
> I would like to close the nomination period, and move on to select our
> protocol.
>
> The best approach will be if supporters of the candidate protocols
> indicate (briefly) why their proposed protocol is suitable. It  
> would also
> be helpful if they were frank about what the weaknesses of their  
> proposal
> are.
>
> And please - this is not an election, it is an interview process.
>
> Thanks,
> Adrian
>
> PS The reason why JP is keeping quite on this is that he is an  
> author of
> draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not  
> occupying the
> chair during this discussion.
>
>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
>

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 05 Oct 2005 09:14:42 +0200

adrian

one specific comment looking at the APP Area response last August (and 
hence the first alternative here below) it stated

"If you have looked at HTTP and don't think it works, then telling us 
where you see problems will help us maybe come up with a better idea."

and may thus be interesting to collect valid input from this list on 
this proposal and send it to the APP Area

note: i think since so far the concern is the processing efficiency 
(even if afaik the PCE requirements did not come with specific numbers 
in terms of computation delay that would allow comparison with the 
processing delay of the message to see whether this latter is indeed 
significant) and some messaging specific to PCC/PCE-PCE communication 
that may require extensions

a last point it may also be important to come up with a clear view on 
the advantages of each of these solutions and not only their potential 
drawbacks

thanks,
- dimitri

Adrian Farrel wrote:

> All,
> 
> I should have been more careful with my acronyms.
> 
> PCECP is the generic protocol. In other words, what the requirements
> describe. The job vacancy we are trying to fill.
> 
> PCEP is JP's (and others) proposed solution.
> 
> Cheers,
> Adrian
> ----- Original Message ----- 
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, September 29, 2005 3:27 PM
> Subject: [Pce] Choosing the PCE protocol
> 
> 
> 
>>Hi,
>>
>>indicate (briefly) why their proposed protocol is suitable. It would
> 
> also
> 
>>PS The reason why JP is keeping quite on this is that he is an author of
>>draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not occupying
> 
> the
> 
> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Oct 2005 16:45:44 +0100

Thanks Dimitri,

> the advantages of each of these solutions and not only their potential

Yes.

In order to adopt any solution we must be clear that folk will implement
it, and underpinning that would be a belief in some quarters that it is a
"good" solution.

So part of the selection process must be to hear from the supporters of
each protocol why they think it is good. To some extent, PCEP has an
unfair advantage here because it has a whole I-D in which to express how
it meets the PCEP requirements, and can claim that its principal advantage
is that it meets those requirements directly. That is why we are taking
some time on the list to allow supporters of other options to put their
case.

That a protocol solution is good because it lacks the defects of another
protocol solution is a small (albeit negative-campaigning) point in its
favour. It is like my Member of Parliament who told me I should vote for
him because he is not from the other party. We should hope for a few more
positive comments in support of any proposal.

Cheers,
Adrian

---

From: [email-masked]
Date: Fri, 7 Oct 2005 12:48:53 -0400 (EDT)

Hi,

My major problems with the PCEP:

a) inability to introduce new constraints, diversities, their relaxation
strategies, optimization criterias, etc. without modifying the protocol;

b) inability to convey policies

Igor

---

From: JP Vasseur <[email-masked]>
Date: Fri, 7 Oct 2005 13:03:35 -0400

Hi Igor,

> b) inability to convey policies

Thanks for your feed-back. Actually this could be easily handled by  
encoding your optimization criterias, policies, ... within a opaque  
Object: we had some discussion about this. There are many other  
protocols adopting a similar approach. The rest of the machinery,  
state machine of PCEP could be entirely re-used (synchronized  
requests, unsolicited notifications, negative replies, ...).

Thanks.

JP.