Subject: [Pce] Alia Atlas' No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Thu, 15 Sep 2016 06:42:32 -0700

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 15 Sep 2016 16:14:48 +0000

Hi Alia, 

Thanks for your comment, see inline... 

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: 15 September 2016 19:13
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Alia Atlas' No Objection on
> draft-ietf-pce-pcep-service-aware-12: (with COMMENT)
> 
> 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
> I am concerned that the 24 bit values of microseconds are being represented
> in IEEE 32-bit floating point.
> 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-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 15 Sep 2016 10:29:47 -0700

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-masked]> wrote:

> email

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 16 Sep 2016 03:59:58 +0000

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-masked]]
Sent: 15 September 2016 23:00
To: Dhruv Dhody <[email-masked]>
Cc: Alia Atlas <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

> From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
> To: The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>

Will this be okay?

Regards,
Dhruv

> [email-masked]<mailto:[email-masked]>

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 15 Sep 2016 21:47:16 -0700

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-masked]> 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-masked]]
> *Sent:* 15 September 2016 23:00
> *To:* Dhruv Dhody <[email-masked]>
> *Cc:* Alia Atlas <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [Pce] Alia Atlas' No Objection on
> 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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 16 Sep 2016 09:44:25 -0400

Hi Dhruv,

Yes, that'd be fine.  The point is to raise awareness of the concern.
I'm assuming that these numbers will rarely get into the multi-second
values,
so it shouldn't have a large impact.

Thanks,
Alia