I am the assigned Gen-ART reviewer for
draft-ietf-pce-comm-protocol-gen-reqs-06.txt
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please wait for direction from your document shepherd or AD
before posting a new version of the draft.
===============================================
Summary: This draft is on the right track but has open issues
to resolve before publication.
===============================================
This draft is well written and is accessible to readers, like
myself, who are not routing (particularly MPLS) experts.
The current version has some rough edges that I feel need attention
before publication. They are listed here in priority order. These
are followed by a few nits that should also be addressed.
ISSUE 1:
The summary of requirements in section 6.4 are inconsistant with
the requirements in the document.
Example: 6.4 contains:
Functionality added to PCECP if transport
protocol provides it SHOULD NOT 6.1.8
while 6.1.8 says
Functionality MUST NOT be added to the PCECP where
the chosen transport protocol already provides it.
Example: 6.4 contains:
Maintain PCC-PCE session NON-RQMT 6.1.2
but 6.1.2 is silent on maintaining sessions
I have not done an exhaustive comparison of the table vs the text.
This is what I found spot-checking a few. A more thorough
reconcilliation
is needed.
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 3:
There is an incorporation of MUST requirements by incomplete
reference in section 6.1.14:
"The PCECP MUST support the requirements specified in the
application-specific requirements documents."
But it's not clear what these requirements documents are. There
is a list in the preceeding paragraph, but only a subset of the
elements in that list have concrete references.
One possible resolution is to state that the protocol must be
extensible, explicitly call out the kinds of extensibility (adding
to the first paragraph of 6.1.14 perhaps) and calling out these
other documents as examples of the users of the extensibility
mechanism
instead of directly requiring support of their requirements here.
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 6 (not as major as the above, but should still be addressed):
There are several places where 2119 terms are used where they
shouldn't be. The large difference in the number of occurances of
MUST outside section 6.4 and inside section 6.4 points to this and
could be used as a mechanism to help find these places.
Examples from 6.1.4:
A list of core objective functions that MUST be supported by the
PCECP is supplied in Section 6.1.17. Specification of objective
functions MUST be future-proofed as described in Section 6.1.14.
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.
Thanks for reading,
RjS
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
