A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
RFC 5886

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

Comment (2010-01-02)
No email
send info
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' **)
No email
send info
  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

Comment (2010-01-06)
No email
send info
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

Comment (2010-01-07)
No email
send info
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.