Hi Igor,
On Oct 7, 2005, at 12:48 PM, [EMAIL PROTECTED] wrote:
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
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.
Igor
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 protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
