A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
Note: This ballot was opened for revision 09 and is now closed.
(Adrian Farrel) Yes
(Jari Arkko) (was Discuss) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Ralph Droms) (was Discuss) No Objection
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:"
(Lisa Dusseault) No Objection
(Pasi Eronen) No Objection
(Russ Housley) No Objection
Comment (2010-01-06 for -** No value found for 'p.get_dochistory.rev' **)
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)
(Cullen Jennings) No Objection
Alexey Melnikov No Objection
(Tim Polk) (was No Record, Discuss) No Objection
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.
(Dan Romascanu) No Objection
(Robert Sparks) No Objection
Magnus Westerlund (was Discuss) No Objection
(Lars Eggert) (was Discuss) Abstain
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.