A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
draft-ietf-pce-monitoring-09
Yes
(Adrian Farrel)
No Objection
(Alexey Melnikov)
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Abstain
Note: This ballot was opened for revision 09 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Alexey Melnikov 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
(was Discuss)
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
(was Discuss)
No Objection
No Objection
(2010-01-02)
Unknown
From section 3: Because the P flag exclusively relates to a path computation request, it MUST be cleared in the two PCEP messages (PCMonReq and PCMonRep message). Should this sentence end with "defined in this document"? Editorial nits in section 3.1; the definition of <pce-list> should come before <svec-list> and the description of the PCMonRep message includes a (seemingly) redundant "where:"
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2010-01-06)
Unknown
The Gen-ART Review by Francis Dupont on 2010-01-06 raised some
comments. Please consider them. These two seem the most important
to me:
- 4.1 page 14: even if MONITORING object has no optional TLV
currently defined, the format of these TLVs must be specified.
I propose the PCEP generic TLV format, RFC 5440 7.1.
- 4.3 page 17: the variance of time is a squared time. I propose to
switch to standard deviation (ecart type in French, the square root
of the variance)
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2010-01-06)
Unknown
The phrase "path computation chain" appears sixteen times, and the phrase "PCE chain" appears seven times. The latter phrase is undefined; are they equivalent terms? If they are equivalent, I would change everything to path computation chain. (If not, please define the term.) In section 9 (Security Considerations), I would suggest an explicit reference to 5440 section 10.7.2. "Request Input Shaping/Policing" in the last sentence, since there is an extensive treatment in that spec. Finally, while it arrived rather late I strongly encourage the authors to review Hannes' thought provoking secdir review.
Lars Eggert Former IESG member
(was Discuss)
Abstain
Abstain
(2010-01-07)
Unknown
Agree with Magnus. The OVERLOAD object seems to be redundant, given that it defines overload in terms of processing delay, and we already have a PROC-TIME object that has that (raw) information. The only different between the two seems to be that using the OVERLOAD object conveys the meaning of "hey, I consider myself overloaded at processing delay X" while using a PROC-TIME object just says "hey, here's my processing delay and it's X". Since there are huge question marks around which control mechanism would actually use the overload information (c.f. the SIP overload issues), I'm not sure both are needed. Also, what control mechanism is envisioned for PCE overload control? This cannot be left up to implementations - a distributed control system needs at least some standardized behavior to get stability and avoid oscillations and livelock.