Adrian, All, I think good arguments have been put forward for supporting PCEP as the selected protocol. And I'm OK to support PCEP too. However:
> Scanning the mails on the list so far I see no strong support > for COPS or HTTP. Well, I've not seen any response to your original request from those who nominated COPS and HTTP: "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." Also, I've not seen too many weaknesses pointed out RE PCEP :-) > 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've been kind of waiting to see a more balanced pros and cons debate, maybe others are as well. > 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. Right, it would be good to hear the pros & cons on COPS & HTTP from the nominators. > 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. Well, I guess we have implementations of COPS & HTTP also, extensions obviously needed to meet PCECP requirements... > 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... Before deciding, IMO it would be better to have a more balanced pros & cons discussion with nominators/supporters of the other 2 candidates speaking up. Thanks, Jerry _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
