A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link
draft-ietf-mpls-number-0-bw-te-lsps-12
Yes
(David Ward)
(Ross Callon)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Tim Polk)
Note: This ballot was opened for revision 12 and is now closed.
David Ward Former IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2008-08-28)
Unknown
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 IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown