adrian,
Adrian Farrel wrote:
Dimitri,
Sorry for the slow response.
Scanning the mails on the list so far I see no strong support for COPS
or HTTP.
If you are in support of either of these you will need to speak up. I
know it can be worrying to stand in front of the IETF juggernaut, but if
you don't speak up you will not be heard. I promise to support you.
i repeated what has been stated in a previous e-mail (not sure i have
been heard ;-)
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."
so please collect valid input from this list on this proposal and send
it to the APP Area
Let's not over-cook the nature of the response from the Applications Area.
In response to our many requests for input from the Applications Area, I
received one response from an individual (Martine Duesrt) that suggested
XML using HTTP. Clearly that individual is willing to help and might be
engaged in the discussions, but I think the Apps Area has punted on this.
Listening to the conversation so far, it seems that the arguments against
HTTP are:
- too many options
- conversation oriented, rather than request response based
- too heavy
If anyone would like to add to that list, I will send it to Martin.
two points here:
- are we in agreement concerning the fraction of time required to parse
the path request/response compared to the real computation time (afaik,
the PCE is meant to off-load time consuming path computation hence this
point becomes important when evaluating performance); are we in
agreement that this fraction of time can even be negligible compared to
the delay the message could experience in certain specific cases ?
- the notion of "lightweight" vs "heavyweight" is still rather
confusing, do we have something more formal ?
We have had several questions and issues about PCEP
(draft-vasseur-pce-pcep-02.txt) as currently specified. It seems to me
that these were deficiencies in the current specification of PCEP
rather than intrinsic faults in the protocol, and that they could be solved
by the definition of appropriate objects. [Please disagree loudly!]
i don't clearly see the distinction you make between "deficiencies in
the current specification from intrinsic faults in the protocol"
Before dealing with your example, let me give two examples of my own.
1. The PCEP spec does not contain a state machine.
Clearly this does not represent a deficiency in the protocol. It is a
documentation deficientcy that the authors say they will solve in a
future revision. I would agree that it might be masking a deficiency
in the protocol.
2. No way to carry encodings of complex constraint interactions.
There has been some talk about the need to encode certain information
such as complex constraint interactions using a language (such as XML)
rather than bits and bytes as we see in most signaling protocols.
It seems to me that this problem is easliy solved by the definition of
an
object that carries an XML payload. This is not an intrinsic problem
with the protocol, but is just a matter of defining the encoding of an
object. The only possible issue I can see is making sure that the
message and object lengths can handle the verbosity of a language
encoding.
on point 2. this would mean that the issue of being verbose disappears
as concern ?
let's
take an example (this may help) that has been already discussed on this
list, the extensibility and flexibility requirement: when introducing
new constraints (for instance) or modifying the set of constraints (for
instance) in this protocol could be too constraining in further being
compliant with this requirement, this pushes me to point out that the
protocol may look like "lightweight" with its known and current list of
objects but would it be also "lightweight" in operations such as upgrade
and other maintenance ?
I think you are mixing "protocol" with "encoding".
i am not sure i am mixing issues, i only think the issue is twofold a
TLV based oriented protocol associates a processing to the TLV; on the
other side you could well define a TLV to carry "opaque" information;
the question then becomes whether it would not be simpler to have a
message-oriented protocol over the selected transport protocol (here, TCP) ?
I believe that
discussions of "lightweight protocol" are intended to refer to protocol
message exchanges, protocol state, and protocol procedures. They are not
intended to refer to bits on the wire - although this is importnat to some
degree, it is not a killer.
but if this is the case then i think we are coming closer to a consensus
that the PCC/E->PCE protocol function is to exchange a set of messages
whose content encoding should be as flexible as possible;
Certainly extensiblity is crucial to any PCECP. Certainly it is possible
to extend XML encoding to include new information, and this can be done in
a backwards compatible way by defining that legacy nodes will reject or
ignore new verbs and adverbs (nouns and adjectives) according to rules
specified within the encoding and/or documentation. But I don't see why
and object/TLV-based encoding is any harder to make extensible.
so if it is to transport messages with structured XML textual content
... why not use a protocol like BEEP for instance ? note that BEEP
session can be transported over TCP (see RFC 3081)
We have had much discussion of why COPS and/or HTTP might not be
appropriate. Many of the reasons suggested have been refuted or argued
with, but this in itself does not amount to a case against PCEP, nor a
case for COPS or HTTP.
We have also had some questions about the function that a pcecp should
or should not provide (for example, should a PCE be able to connect to a
PCC?). We need to do two things:
1. Go back to the requirements I-D with these considerations and
add/remove them according to consensus.
2. Examine the candidate protocols only against the requirements I-D
and not against other putative requirements.
[Safety note: when I refer to vendors or service providers below, I do
not mean to imply that an individual represents the view of any
corporation or that anyone participating in the IETF does so other
than as an individual.]
The bottom line that I see forming is that several vendors support
PCEP by co-authoring, and several service providers express interest
in seeing this development so that they can further assess the value
of PCE. I also see strong interest expressed by at least one vendor
in producing an implementation.
these objectives are different in nature, there is a difference in
assessing value of PCE and assessing value of the PCC/PCE->PCE
communication protocol, the "user" will assess value from what the
transaction allows (as long as the communication protocol generic
requirements are fulfilled)
Yes. And your point is?
that we are creating an inverse value chain only, most issues we are
discussing are not specifically driving value for the PCE users; this is
part of the concern that feature requirement work just started (see
inter-area, inter-AS, and multi-layer requirements) ... i think at the
end the main question is the PCE WG sole purpose to define the specific
communication protocol to be used between the requester and the
computing element or to use this protocol in order to address the
initial problem(s) the WG intended to solve ? i think the response to
this question is a conjunction of both elements
I am saying that we must select a protocol. Also that we should select a
protocol this century.
i agree, but as you are implying timely decision, i would like to
remember that a "new" protocol is not necessarily the less time-
consuming solution
I am saying that I am seeing support expressed for selecting PCEP. But I
am also saying that while some of the support is in order to implement,
some of the support is so that PCE can be the subject of experimentation.
indeed but the initial issue remains the PCE approach will be gauged by
the problem space it really solves; on the other side we all perfectly
know that this communication protocol is just going to be the mechanism
on top of which a series of specific path computation request will be
constructed
In the end, while we must strive not to do things that break the
Internet, we should also support the running code principle. If the only
proposal that anyone is willing to implement or experiment with is
Protocol X, then that is what we will choose unless it is unfixably
broken.
Failing further comment we appear to be on the verge of selecting PCEP
(draft-vasseur-pce-pcep-02.txt)
Note that the acceptance of one solution or another at this stage does
*NOT* imply that the solution is immune from significant changes. In
fact, once a solution is owned by the WG, I would expect to see a lot of
input and modification especially from the implementers.
sure, another question is also to have a better view on the system
expected responsiveness this may help also in assessing which level of
integration we lay have to consider
yep, moreover, looking at the heterogeneity of systems that can host a
PCE (and even a PCC) and with the elements we have at hand it is indeed
premature to come out with a "one siwe fits all" like-answer
The discussion continues...
indeed,
thanks,
- dimitri.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
