Hi Dhruv, thank you for the clarification. I agree, using time format in this case is not necessary at all.
Regards, Greg On Thu, Sep 15, 2016 at 8:59 PM, Dhruv Dhody <[email protected]> wrote: > Hi Greg, > > > > The case with this draft is that IGP drafts [RFC7471] and [RFC7810] uses > 24 bit integers for delay and delay variation already to flood this in > TEDB. > > The PCEP [RFC5440] defined METRIC value as 32 bit IEEE floating point > format. Changing that in this extension doesn’t seem wise. > > > > It is important to note that this draft is not about measurements, but how > to use delay/delay-variation as constraints/criteria and use the date in > TEDB for calculating a suitable E2E path (and thus before the path is setup > and data flowing). I personally don’t see the benefit in changing format > now. > > > > Thanks! > > Dhruv > > > > *From:* Greg Mirsky [mailto:[email protected]] > *Sent:* 15 September 2016 23:00 > *To:* Dhruv Dhody <[email protected]> > *Cc:* Alia Atlas <[email protected]>; The IESG <[email protected]>; > [email protected]; [email protected]; > [email protected] > *Subject:* Re: [Pce] Alia Atlas' No Objection on > draft-ietf-pce-pcep-service-aware-12: (with COMMENT) > > > > Dear All, > > delay and delay variation are usually calculated using timestamps > collected at two endpoints of the path. AFAIK, there are two formats, NTP > and IEEE-1558v1/v2, being used in OAM protocols to measure Latency/Jitter > with different precision determined by length of fractional seconds field. > Hence my question, wouldn't it be easier, more intuitive to use one of the > formats or, even better, allow both with explicit indication of the format > being used, e.g. as in RFC 6734. > > > > Regards, > > Greg > > > > On Thu, Sep 15, 2016 at 9:14 AM, Dhruv Dhody <[email protected]> > wrote: > > Hi Alia, > > Thanks for your comment, see inline... > > > > -----Original Message----- > > From: Pce [mailto:[email protected]] On Behalf Of Alia Atlas > > Sent: 15 September 2016 19:13 > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected] > > Subject: [Pce] Alia Atlas' No Objection on > > draft-ietf-pce-pcep-service-aware-12: (with COMMENT) > > > > Alia Atlas 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 am concerned that the 24 bit values of microseconds are being > represented > > in IEEE 32-bit floating point. > > A quick look at conversions indicates that all integers will up to 6 > > significant figures can be converted without loss of precision. That > > implies that values of over 1 second may not be accurately sent. It > would > > be useful to at least refer to the precision issue in the document. I > don't > > expect that the loss of precision at the microsecond level is critical. > > > > > > [Dhruv] I could add a sentence for delay and delay variation - > > The conversion from 24 bit integer to 32 bit IEEE > floating point could introduce some loss of precision. > > Will this be okay? > > 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 > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
