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. > > 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. > 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 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. > > 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? 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. > > 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 > > > The discussion continues... > > indeed, Thanks, Adrian _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
