Subject: [Pce] Selecting a PCE Communication Protocol - Pulling the threads together

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Oct 2005 21:09:03 +0100

Hi,

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.

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!]

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.

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.

The discussion continues...

Adrian

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 13 Oct 2005 12:22:55 +0200

hi adrian

> 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

> 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" 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 ?

> see strong interest expressed by at least one vendor in producing an

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)

> 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

> The discussion continues...

indeed,

thanks,
- dimitri.

> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 22 Oct 2005 13:47:19 +0100

Dimitri,

Sorry for the slow response.

> so please collect valid input from this list on this proposal and send

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.

> 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.

> let's

I think you are mixing "protocol" with "encoding". 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.

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.

> > add/remove  them according to consensus.
> > not against other putative requirements.
> >

Yes. And your point is?

I am saying that we must select a protocol. Also that we should select a
protocol this century.

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.

> > The discussion continues...

Thanks,
Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 23 Oct 2005 16:55:41 +0200

adrian,

Adrian Farrel wrote:
>>>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.
>>

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 ?

>>>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!]
>>

on point 2. this would mean that the issue of being verbose disappears 
as concern ?

> 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

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;

> 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 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
>>>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.
>>

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

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

> 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.
>>>
>>>*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.
>>

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

thanks,
- dimitri.