hi adrian
Adrian Farrel wrote:
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.
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
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" 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 ?
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)
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,
- dimitri.
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
