Hi Mirja, Yes, thanks Mirja for you detailed review.
As Dhruv noted, this is not representing an average utilization, but the current bandwidth utilization. As Dhruv noted, we could swap this sentence in the Abstract for the term later used in section 4.2.2 "actual". For me, though, current bandwidth utilization is a common (simple) term used often by operational folks, and it has a time element clarification. The document has been reviewed quite extensively by others, so I'm not convinced about the need to change this sentence of the Abstract. We'll discuss it more among the Chairs and authors. I think Dhruv has answered your other comments. As noted, we'll discuss any changes among the Chairs and authors (and WG if needed). Thanks Dhruv! Deborah > -----Original Message----- > From: iesg [mailto:[email protected]] On Behalf Of Dhruv Dhody > Sent: Thursday, September 15, 2016 1:37 AM > To: Mirja Kuehlewind <[email protected]>; The IESG <[email protected]> > Cc: Dhruv Dhody <[email protected]>; [email protected]; draft-ietf-pce-pcep- > [email protected]; [email protected] > Subject: RE: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pcep- > service-aware-12: (with COMMENT) > > Hi Mirja, > > Let me thank you for the detailed review and comments. > I have tried to answer your comments, please see inline. > The working copy with all comments received during the last call process is > also attached. > > > -----Original Message----- > > From: Pce [mailto:[email protected]] On Behalf Of Mirja Kuehlewind > > Sent: 15 September 2016 01:44 > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected] > > Subject: [Pce] Mirja Kühlewind's No Objection on > > draft-ietf-pce-pcep-service-aware-12: (with COMMENT) > > > > 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...? > > > > [Dhruv] The intention is to distinguish it with the "reserved bandwidth", > which has been used during path computation so far. The reserved bandwidth > is independent of the forwarding state and thus more static in nature, the > bandwidth utilization on the other hand looks at what is happening with the > traffic. > > I changed "current" to "actual", to avoid confusion. > > > - 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. > > [Dhruv] RFC7810 and RFC7471 is the place where the values are flooded and > it is evident that averages are applied. As I have removed the word > "current", I > am hoping that no further clarification would be needed. > > > > > - section 3 could be removed. It didn't really help me and the normative > > language here is actually a little bit confusing to me. > > > > [Dhruv] As I mentioned to Ben, this section was written in a spirit that > historically PCE WG has published requirement RFCs and text exist about the > key requirements for the PCEP extensions along with the extension itself. I > offered to move it to appendix in case you feel strongly about this. > > > - 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? > > > [Dhruv] RFC7823 stated - > > An end-to-end bound on delay variation can be used similarly as a > constraint in the path computation on what links to explore where the > path's delay variation is the sum of the used links' delay > variations. > > The consensus was that since this is being computed before the path is > signaled, sum is a good enough indication 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." > > > > [Dhruv] We wanted to keep the door open for an implementation to use > some enhanced mechanism later on. This was checked with performance > directorate some time back. > > > - 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... > > > > [Dhruv] Ack. This has been done as part of OPS directorate review by Jouni > Korhonen. > > > - 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) > > > > [Dhruv] The main reason was because we did not have something similar for > LRBU in those RFCs and thus a new term for LRBU was needed to be deduced > from other parameters as explained below. > > Also the "Utilized Link Bandwidth" ([RFC7471] and [RFC7810]) is the actual > bandwidth utilization of that link in bytes per second. > Since each link would be of different capacity (maximum bandwidth) using > the exact value during path computation is not suitable. > During path computation usage of percentage is better suited and thus we > termed it differently as LBU and LRBU. > > I have updated the formula to avoid using the term LBU, and instead used > utilized bandwidth, which I hope would clear up the confusion. > > > - 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... > > > > [Dhruv] RFC3630 and RFC5305 defined > - Maximum Link Bandwidth > - Maximum Reservable Link Bandwidth > - Unreserved Bandwidth > > RFC7471 and RFC7810 defined > - Residual Bandwidth = Maximum Bandwidth - (bandwidth allocated to RSVP- > TE LSPs) > - Available Bandwidth = Residual Bandwidth - (bandwidth used for the actual > forwarding of non-RSVP-TE LSPs) > - Utilized Bandwidth = actual utilization of the link > > In this draft, > - LBU = (utilized bandwidth / maximum bandwidth) * 100 => includes both > RSVP-TE and non-RSVP-TE > > To deduce only the utilization for the reservable RSVP-TE LSPs > - LRBU = ((utilized bandwidth - (residual bandwidth - available bandwidth))/ > maximum reservable bandwidth) * 100 > > The key is (residual bandwidth - available bandwidth) > =(residual bandwidth - (residual bandwidth - (bandwidth used > for the > actual forwarding of non-RSVP-TE LSPs))) > = bandwidth used for the actual forwarding of non-RSVP-TE LSPs > > So when we deduct this from utilized bandwidth, we are left with the > bandwidth used for the actual forwarding of RSVP-TE LSPs. > > I hope this clarify the calculation. > > > - 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. > > > > [Dhruv] The utilization percentage needs to be checked on each candidate > link during path computation, and that was the reason for the initial wording. > I feel "a path with LBU or LRBU" would be incorrect. > > > - "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? > > > > [Dhruv] We have followed the general practice done in PCEP. Having BU > object behave differently from METRIC object doesn’t seem right. > > > - "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...? > > > > [Dhruv] Yes, that is as per the behavior in RFC5440 and we are just restating > that. > Adrian requested a change, the text in the working copy now says - > > If the BU object is unknown/unsupported, the PCE MUST follow > procedures defined in [RFC5440]. That is, if the P bit is set, the > PCE sends a PCErr message with error type 3 or 4 (Unknown / Not > supported object) and error value 1 or 2 (unknown / unsupported > object class / object type), and the related path computation request > MUST be discarded. If the P bit is cleared, the PCE is free to > ignore the object. > > > - 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)! > > > [Dhruv] I checked with my AD, at this stage we do not want to make change in > the order. > > Thanks again for your review and questions. > > Regards, > Dhruv > > > > > _______________________________________________ > > Pce mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
