A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link
RFC 5330
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
(David Ward; former steering group member) Yes
(Ross Callon; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss, No Objection) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Ben Campbell provided comments on -09 of this document based on his
Gen-ART Review, and they have not been addressed. The Gen-ART Last
Call comments were mostly editorial, and all minor. Since the
comments are minor, I am not entering a DISCUSS, but it is really
bad form to ignore Last Call comments. Please be more respectful
of reviewer time in the future.
Since others have entered DISCUSS positions on this document,
please consider these comments from Ben Campbell.
Abstract:
Please expand TLV and IS-IS on first use. Expanding OSPF would not
hurt, but it is probably well-known enough not to require expansion.
s/"statistical assumption"/"statistical assumptions"
(should be plural.)
Requirements Language:
It's a bit odd to see this prior to the Table of Contents. I usually
see it in the terminology section. I don't know if it matters.
Section 1:
Most of the terms are just acronym expansions. It might be nice to put
in short definitions, unless all of the terms are sufficiently well-
known not to need definitions.
Section 2, paragraph 1:
I find the heavy use of parentheses to detract from the flow of the
paragraph. Also, when nesting parentheses, please use other symbols.
For example ( ... [ ... { ... } ... ] ... ) instead of ( ... ( ...
( ... ) ... ) ... )
paragraph 2:
s/"other metric"/"other metrics"
(should be plural.)
"Unfortunately,
for instance in the presence of ECMPs (Equal Cost Multi-Paths) in
symmetrical networks when unconstrained TE LSPs are used, such
metrics (e.g. path cost, number of hops, ...) are usually ineffective
and may lead to poorly load balanced traffic."
I found this sentence hard to follow. Can it be simplified?
paragraph 3:
s/"statistical assumption"/"statistical assumptions"
(should be plural.)
Also, can you offer a sentence or two explaining what you mean by
"statistical assumptions"? I think I know what you mean, but I don't
think it will be obvious to all readers.
paragraph 5:
A comma would be a better choice than parentheses in this context.
paragraph 7:
Why is it okay to omit unconstrained TE LSPs that are provisioned?
Section 3.1, definition of "Value"
Is the encoding of the numeric value well-known for this context, or
should this document specify it?
Section 3.2, definition of "Value"
Is the encoding of the numeric value well-known for this context, or
should this document specify it?
Section 4 , title:
I'm not sure what the title means. I suggest "Procedures".
paragraph 1:
Is that intended to be a normative SHOULD?
Section 5:
The text said the type numbers were to be assigned by IANA, with 23
being a suggested value. That is not clear in the IANA considerations.
Section 6:
Can the information carried in this new parameter ever be sensitive,
or useful to an attacker? I'm not saying it is, but it might be useful
to mention this one way or another in the security considerations.
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection