Hi Dhruv, please see inline.
> Am 15.09.2016 um 07:37 schrieb Dhruv Dhody <dhruv.dh...@huawei.com>: > > 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:pce-boun...@ietf.org] On Behalf Of Mirja Kuehlewind >> Sent: 15 September 2016 01:44 >> To: The IESG <i...@ietf.org> >> Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org; >> pce-cha...@ietf.org >> 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. See my previous mail. > >> - 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. > It’s fine for me. A note to see for RFC7810 and RFC7471 on how these value are computed could still be good but not absolutely necessary. >> >> - 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. For me it was really irritating. I don’t see a need to hold up the spirit of an historical wg. I would still recommend to move it to the appendix. > >> - 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. That’s okay but this text talks about an end-to-end BOUND which is a maximum and not the average. You need to reflect this correctly in your text. E.g.: "An implementation therefore, MAY use the sum of the average delay variation of link along a path to derive a maximum bound for delay variation of the path.“ > >> 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. I was already assuming that this come from the directorate review. The intention is good but I would actually give some more context here. Part of this is explaining that the provided calculation is only giving an upper bound and not an average and therefore other calculation could improve the results leading to a smaller average variation value. > >> - 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. After publication TBD8 will be replaced and the value will be assigned, so „is to be“ will be wrong. Either you change this now or you need to make an RFC editor note on this to make sure this will not be overlooked. > >> - 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. Yes, I got the intention, just the wording was confusing. I think updating the formula (and probably something in the text before the formula) will help. Thanks! > >> - 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. Okay now i got it. Not sure which step was missing in the draft. Maybe i misunderstood residual bandwidth. Maybe spell out the terms you’ve explained above more clearly. Thanks! > >> - 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. Okay, may concern again came from the thing on time-scales for measuring values where bandwidth utilization could be the current value on a short time scale. This is nothing big but how about the following, just to make it even more concrete: "A PCE that supports this object MUST ensure that no link on the computed path has an LBU or LRBU percentage exceeding the given value." > >> - "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. That's not a good reason. Important is to do the right thing for this object. The reason why you have the chance to specify this separately in this document is because it might make sense to do something different for different objects. Any I don’t feel strong about this… > >> - "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. I really would remove the normative language here as restating normative requirements is bad practice. That would be: "If the BU object is unknown/unsupported, the PCE is expected to 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 will 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. Okay. Usually changing the order without changing the content is not a problem. This request was only to double-check but whatever you decide is fine with me! Mirja > > Thanks again for your review and questions. > > Regards, > Dhruv > >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > <Diff_ draft-ietf-pce-pcep-service-aware-12.txt - > draft-ietf-pce-pcep-service-aware-13.txt.html><draft-ietf-pce-pcep-service-aware-13.txt><draft-ietf-pce-pcep-service-aware-13.xml> _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
