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

[Greg Mirsky]

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  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:gregimir...@gmail.com]
> *Sent:* 15 September 2016 23:00
> *To:* Dhruv Dhody 
> *Cc:* Alia Atlas ; The IESG ;
> pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org;
> pce-cha...@ietf.org
> *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 
> wrote:
>
> Hi Alia,
>
> Thanks for your comment, see inline...
>
>
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Alia Atlas
> > Sent: 15 September 2016 19:13
> > To: The IESG 
> > Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org;
> > pce-cha...@ietf.org
> > 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
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Dhruv Dhody]

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:gregimir...@gmail.com]
Sent: 15 September 2016 23:00
To: Dhruv Dhody 
Cc: Alia Atlas ; The IESG ; pce@ietf.org; 
draft-ietf-pce-pcep-service-aw...@ietf.org; pce-cha...@ietf.org
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 
> wrote:
Hi Alia,

Thanks for your comment, see inline...

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On 
> Behalf Of Alia Atlas
> Sent: 15 September 2016 19:13
> To: The IESG >
> Cc: pce@ietf.org; 
> draft-ietf-pce-pcep-service-aw...@ietf.org;
> pce-cha...@ietf.org
> 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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Greg Mirsky]

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

> Hi Alia,
>
> Thanks for your comment, see inline...
>
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Alia Atlas
> > Sent: 15 September 2016 19:13
> > To: The IESG 
> > Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org;
> > pce-cha...@ietf.org
> > 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
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[BRUNGARD, DEBORAH A]

Hi Spencer,

This document is on how a PCE utilizes the IGP information of RFC7471 (OSPF) 
and RFC7810 (ISIS). Both documents use the term “current” in their definitions. 
And also use “actual”. For this document, we don’t want to re-invent 
terms/definitions for already defined IGP information.

Now I need to get to my “current” lunch before it’s not current☺
(Thanks for all the interest!)
Deborah


From: Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
Sent: Thursday, September 15, 2016 11:43 AM
To: BRUNGARD, DEBORAH A 
Cc: Dhruv Dhody ; Mirja Kuehlewind 
; The IESG ; Dhruv Dhody 
; pce@ietf.org; 
draft-ietf-pce-pcep-service-aw...@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] Mirja Kühlewind's No Objection on 
draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

Hi, Deborah/Dhruv,

On Thu, Sep 15, 2016 at 9:03 AM, BRUNGARD, DEBORAH A 
> wrote:
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.

Mirja may be having a post-telechat beer, and this is for her ballot position, 
but I'm thinking that "time element clarification" is key here. If "current 
bandwidth utilization" is measured on a scale of minutes or larger, it usually 
doesn't freak out TSV folk, but if it's measured on a scale of single-digit 
seconds or smaller, it usually does.

At least, it freaks me out. I spent most of the time I was responsible AD for 
one particular working group talking to them about how frequently they should 
be adjusting cost maps based on bandwidth utilization and other, basically 
instantaneous, transport metrics. The more frequently people make adjustments, 
the more likely you are to see oscillation between paths that you don't really 
want to see. For a distributed system, you're always basing decisions on 
something in the past that may have changed since you found out about it.

I'll let Mirja take it from here on resolving her comment (because she might be 
talking about something completely different), but wanted to chime in, so that 
her comment doesn't become my comment, too.

Thanks,

Spencer
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Jari Arkko's Yes on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[Jari Arkko]

Thanks. This all makes sense.

Jari




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Jari Arkko's Yes on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[Dhruv Dhody]

Hi Jari, 

Thanks for your comments, please see inline...

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jari Arkko
> Sent: 15 September 2016 12:53
> To: The IESG 
> Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org;
> pce-cha...@ietf.org
> Subject: [Pce] Jari Arkko's Yes on draft-ietf-pce-pcep-service-aware-12:
> (with COMMENT)
> 
> Jari Arkko has entered the following ballot position for
> draft-ietf-pce-pcep-service-aware-12: Yes
> 
> 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:
> --
> 
> The document should probably say more about how frequently information can
> be updated and recomputation can occur; there's a possibility that too
> frequent adjustment creates a flip flop effect where traffic moves to a new
> path, performance degrades, etc.
> 
[Dhruv] I have added this text in the section 1 - 

   [RFC7471] and [RFC7810] describe various considerations regarding -

   o  Announcement thresholds and filters

   o  Announcement suppression

   o  Announcement periodicity and network stability

   The first two provide configurable mechanisms to bound the number of
   re-advertisements in IGP.  The third provides a way to throttle
   announcements.  Section 1.2 of [RFC7823] also describes the
   oscillation and stability considerations while advertising and
   considering service aware information.

> I was curious about the definition of the P2MP packet loss as being the 
> highest
> among the individual path losses. Is there some basis in some measurement
> documents for instance for this definition? It would seem to me that other
> definitions would also be possible, e.g., ones that take the aggregate loss
> into account in some fashion.
> 

[Dhruv]: I do not have a reference for this, it just made good intuitive sense 
to go this way during discussion with authors/WG while considering packet loss 
for P2MP TE. Other definitions are possible, and can be added by defining new 
OF/metric in future.   

Let me know if you would like to see further change. 

Regards,
Dhruv  

> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Deborah/Dhruv,

On Thu, Sep 15, 2016 at 9:03 AM, BRUNGARD, DEBORAH A  wrote:

> 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.


Mirja may be having a post-telechat beer, and this is for her ballot
position, but I'm thinking that "time element clarification" is key here.
If "current bandwidth utilization" is measured on a scale of minutes or
larger, it usually doesn't freak out TSV folk, but if it's measured on a
scale of single-digit seconds or smaller, it usually does.

At least, it freaks me out. I spent most of the time I was responsible AD
for one particular working group talking to them about how frequently they
should be adjusting cost maps based on bandwidth utilization and other,
basically instantaneous, transport metrics. The more frequently people make
adjustments, the more likely you are to see oscillation between paths that
you don't really want to see. For a distributed system, you're always
basing decisions on something in the past that may have changed since you
found out about it.

I'll let Mirja take it from here on resolving her comment (because she
might be talking about something completely different), but wanted to chime
in, so that her comment doesn't become my comment, too.

Thanks,

Spencer
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[BRUNGARD, DEBORAH A]

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:iesg-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Thursday, September 15, 2016 1:37 AM
> To: Mirja Kuehlewind ; The IESG 
> Cc: Dhruv Dhody ; pce@ietf.org; draft-ietf-pce-pcep-
> service-aw...@ietf.org; pce-cha...@ietf.org
> 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:pce-boun...@ietf.org] On Behalf Of Mirja Kuehlewind
> > Sent: 15 September 2016 01:44
> > To: The IESG 
> > 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.
> 
> > - 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 

[Pce] Jari Arkko's Yes on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[Jari Arkko]

Jari Arkko has entered the following ballot position for
draft-ietf-pce-pcep-service-aware-12: Yes

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:
--

The document should probably say more about how frequently information
can be updated and recomputation can occur; there's a possibility that
too frequent adjustment creates a flip flop effect where traffic moves to
a new path, performance degrades, etc.

I was curious about the definition of the P2MP packet loss as being the
highest among the individual path losses. Is there some basis in some
measurement documents for instance for this definition? It would seem to
me that other definitions would also be possible, e.g., ones that take
the aggregate loss into account in some fashion.


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce