Path Computation Element (PCE) Communication Protocol Generic Requirements
RFC 4657
Yes
No Objection
No Record
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert No Objection
(Ross Callon; former steering group member) Yes
(Brian Carpenter; former steering group member) (was Discuss) No Objection
Less concrete issues from Gen-ART review by Robert Sparks:
ISSUE 2:
The extensibility requirements demand arbitrary objective
functions. A discussion of the security implications of this
requirement is needed. There are probably additional requirements
on the protocol to be identified focusing on mitigating the risk
of, for example, a PCC using complex objetives to intentionally drive
a PCE into resource exhaustion. Does the protocol need to give the PCE
tools to say "I tried to do that, but it's turning out to be harder
than my policies allow."?
ISSUE 4:
There are several requirements of PCEs that have been captured
here as requirements of the PCECP. Section 6.1.15 requires that
the protocol "scale well", where it really means that the system
using the protocol scales well. The numbers in this section are
capacity and performance numbers for a PCE, and they are useful
when designing the PCECP to make sure the protocol itself makes
achieving those numbers sane. This section should be reworded to
make this obvious.
Similarly, section 8 should separate requirements on the protocol
from the motivational requirements on CPE implementations (2119
words shouldn't be used in that motivation).
ISSUE 5 (Apologies if my lack of domain expertise led me to miss
something obvious here):
Section 6.3.3 requires the protocol to carry information about
the state of the network to the PCE that would normally come from
the TED. Does this not introduce security concerns? Could a PCC
use this poison CPE calculations for other PCCs? If this capability
exists, there needs to be discussion about how the data gets used
by the PCE (does it cache it?), but that discussion doesn't belong
in this document. I suggest at a minimum that some discussion of
the ramifications of this capability be included in the security
consideration section of this document.
ISSUE 7:
The purpose of 6.2.1 is not clear. What is the real requirement
being placed on the protocol, and how can we evaluate the protocol
against that requirement. If there are no such explicit requirements,
I suggest this be rewritten as advice on where the protocol is expected
to be used and not use 2119 terms at all.
I'm particularly puzzled about what impact operating in environments
including
"- packet and non-packet networks"
is intended to have on the protocol itself.
Nits:
The draft passes the idnits checker (in spirit at least).
The checker complains about the reference to 2119 in the
boilerplate, and the unexpected use of
"Authors' and Contributors' Addresses".
These nits are in no particular order:
NIT 1:
The references to I-Ds that are works in progress do not
include draft names, Please add them.
NIT 2:
Please expand PCE in the title.
NIT 3:
Section 6.1.6 uses "notification message" which is not yet
defined - a forward reference would be helpful.
NIT 3:
Section 6.1.11 requires unsolicited notifications, but doesn't
really define them. Are these reliable messages? Do they get
responses? More detail about what's really being required would
make the document more useful.
NIT 4:
The final requirement in 6.1.15 is redundant with requirements
in both 6.1.8 and section 8. Consolodating those would make the
document stronger.
NIT 5:
I suggest deleting "easily" in section 6.1.14:
The PCECP MUST be easily extensible -> The PCECP MUST be extensible
NIT 6:
Sections 6.1.16 and .17 share some language that confuses me:
"does not mean that the constraint must not be supported"
and
"does not mean that the objective function may not be supported"
Is there a way to say this with fewer negations?
You are trying to reinforce that these sets are extensible. Maybe
you could just say that instead?
NIT 7:
The first sentence of 6.2.2 has at least two discrete requirements
embedded in it. It would be easier to evaluate against the eventual
protocol definition if these were separated.
NIT 8:
It's not clear to me what "resynchronization of information" means in
section 6.3.2. Is there any way to add detail? Is it obvious to the
community using this document what information is being resynchronized?
NIT 9:
Section 6.3.3, third paragraph. I suggest changing
"large number of PCCs is going to simultaneously" to
"large number of PCCs will simultaneously".
A couple of final comments that I didn't think worthy of
being called an issue or a nit:
The draft requires response aggregation, but doesn't discuss
the ramifications this will have on the reliability mechanisms
that you will either use from a selected transport or have to
build above it. Pointing out that there are non-trivial issues
here would probably be useful.
The security consideration section doesn't capture any thinking
your group may have put in so far towards threats from elements
that are part of the architecture. Capturing early thinking here
will go a long way.
(Dan Romascanu; former steering group member) No Objection
1. From Section 8: 'PCECP operations MUST be modeled and controlled through appropriate MIB modules.' It looks to me that there are enough specific differences between PCCs and PCEs to lead to the need of defining separate MIB modules. I suggest that this is mentioned in Section 8. 3. 'The operator MUST be able to determine PCECP historical interactions and the success rate of requests using data from MIB modules.' The way this phrase is written the use of capitalization does not seem justified. Maybe a beter text would be: 'The MIB modules MUST provide information that will allow an operator to PCECP historical interactions and the success rate of requests.' 3. 'The new MIB modules should also be used to provide notifications (traps) when thresholds are crossed or when important events occur.' This is extremely vague and general for a requirement. I wsuggest that sepcific information be provided about what type of faults and events are critical and need to be reported in notifications. Maybe this paragraph needs to be merged with the last paragraph, where there is some mention about congestion and rate limitation indications.
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) (was No Record, Discuss) No Objection
(Sam Hartman; former steering group member) (was Discuss) No Objection
(Ted Hardie; former steering group member) No Objection
(Cullen Jennings; former steering group member) (was No Objection) No Record
(David Kessens; former steering group member) No Record