Mirja Kühlewind has entered the following ballot position for draft-ietf-pce-pcep-service-aware-12: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have quite a few comments and some parts really need fixing as things seems wrong to me. However, all these things are no big issues in itself that do not justify a discuss. I strongly recommend to discuss these points and apply changes where appropriate to make these metrics useful by providing the right information. - This doesn't seem right to mean: "The link bandwidth utilization (the total bandwidth of a link in current use for the forwarding)" Especially the word "current" is irritating as I strongly assume you'd be interested in something like the average utilization...? - In general I would clarify that you always talk about averages and not the current values because those change too dynamically to use them for path computation. - section 3 could be removed. It didn't really help me and the normative language here is actually a little bit confusing to me. - section 4.2.1: This also doesn't seem to be fully correct: "An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the average delay variation of the Path." I would assume that the average path delay variation is NOT the sum of the link variation. What you get is the maximum variation of the average link delay variation... not sure if that's the best metric to provide for path computation. Maybe it would be more useful to use the maximum of the average link delay variation as an extimate for the path delay variation? Also not sure what exactly the next sentence should tell me: "An implementation MAY also use some enhanced composition function for computing the average delay variation of a path." - OLD: "The value for the P2MP path delay metric type (T) = TBD8 is to be assigned by IANA." NEW: "The value for the P2MP path delay metric type (T) is TBD8." Also in the next two sections... - The term "Link Bandwidth Utilization (LBU)" is really confusing because I thought that utilization always is a value in percentage. I would propose to go inline with [RFC7471] and [RFC7810] and call it "Utilized Link Bandwidth"! (Similar for next section) - section 4.2.2.: Really? "The actual bandwidth by non-RSVP-TE traffic can be calculated by subtracting the available Bandwidth from the residual Bandwidth ([RFC7471] and [RFC7810]). Once we have the actual bandwidth for non-RSVP TE traffic, subtracting this from LBU would result in LRBU." Isn't the bandwidth utilization/ulilized bandwidth inculding the Link Reserved Bandwidth Utilization...? Not sure if I get this part correctly... - section 4.2.3.1: OLD "A PCE that supports this object MUST ensure that no link on the computed path has bandwidth utilization (LBU or LRBU percentage) exceeding the given value." NEW "A PCE that supports this object MUST compute a path with LBU or LRBU percentage that does not exceed the given value." I don't think the thing stated in the original sentence is possible based on the given information in the LBU/LRBU. - "If, for a given request, two or more instances of a BU object with the same type are present, only the first instance MUST be considered and other instances MUST be ignored." Maybe it's better to consider the lowest value instead of the first instance? - "If a PCE receives a PCReq message containing a BU object, and the PCE does not understand or support the BU object, and the P bit is clear in the BU object header then the PCE SHOULD simply ignore the BU object." Isn't this the default behavior? How should a PCE that does support this draft/understand the BU object do any actions...? Similar, the next part: "If the PCE does not understand the BU object, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object) and Error-value = 1 (Unrecognized object class) as per [RFC5440]." Just remove those two paragraphs...? - In general, had the feeling that the order of the document is a little up-side-down. However, I'm not sure if changing the order helps. Maybe double-check (also to avoid redunancy)! _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
