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.

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.

(Adrian Farrel; former steering group member) Yes

Yes ( for -)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ralph Droms; former steering group member) (was Discuss) No Objection

No Objection (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:"

(Robert Sparks; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2010-01-06 for -)
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)

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection (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.