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

[Dhruv Dhody]

Hi Mirja, 

See inline...

> -Original Message-
> From: Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net]
> Sent: 16 September 2016 17:46
> To: BRUNGARD, DEBORAH A 
> Cc: Spencer Dawkins at IETF ; Dhruv Dhody
> ; draft-ietf-pce-pcep-service-aw...@ietf.org;
> pce@ietf.org; Dhruv Dhody ; pce-cha...@ietf.org;
> The IESG 
> Subject: Re: [Pce] Mirja Kühlewind's No Objection on
> draft-ietf-pce-pcep-service-aware-12: (with COMMENT)
> 
> Hi Deborah, hi Spencer,
> 
> Spencer, thanks for adding on to this. Yes, that’s where my concern comes
> from.
> 
> I know that this only tries to use what's already done in RFC7471 (OSPF)
> and RFC7810 (ISIS) but the wording is used differently there. Sorry for
> being picky but as this is actually only a wording issue it can probably
> be resolved easy. The point is RFC7471 and RFC7810 carefully only talk about
> the current measurement value (which could have been measured over a long
> time period - and therefore is an average for this measurement time period).
> Or the talk about the actual utilization compared to the reserved bandwidth
> which is actually what is probably meant here.
> 
> What’s about the following change to the abstract:
> 
> Either remove the brackets:
> 
> "The link bandwidth utilization is another
>important factor to consider during path computation.“
> 
> Or write down what Dhruv actually said:
> 
> „The link bandwidth utilization (the actual
>bandwidth used without any reserved bandwidth) is another
>important factor to consider during path computation.“


[Dhruv] I would not like to say "the actual bandwidth used without any reserved 
bandwidth" as "without" is problematic. The relationship is "in comparison 
to"...  

I would like to keep text as - 

   "The link bandwidth utilization (the total
   bandwidth of a link in actual use for the forwarding) is another
   important factor to consider during path computation."


The "actual" has been used in RFC7471 / RFC7810 as in - 

   For a link or forwarding adjacency, bandwidth
   utilization represents the actual utilization of the link (i.e., as
   measured by the advertising node).

I hope this is okay?

Regards,
Dhruv

> 
> For other comments, please see may next mail in reply to Dhruv's mail.
> 
> Mirja
> 
> 
> > Am 15.09.2016 um 18:10 schrieb 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 currentJ
> > (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, 

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

[Mirja Kuehlewind (IETF)]

Hi Dhruv,

please see inline.

> Am 15.09.2016 um 07:37 schrieb Dhruv Dhody :
> 
> 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. 

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 

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

[Mirja Kuehlewind (IETF)]

Hi Deborah, hi Spencer,

Spencer, thanks for adding on to this. Yes, that’s where my concern comes from.

I know that this only tries to use what's already done in RFC7471 (OSPF) and 
RFC7810 (ISIS) but the wording is used differently there. Sorry for being picky 
but as this is actually only a wording issue it can probably be resolved easy. 
The point is RFC7471 and RFC7810 carefully only talk about the current 
measurement value (which could have been measured over a long time period - and 
therefore is an average for this measurement time period). Or the talk about 
the actual utilization compared to the reserved bandwidth which is actually 
what is probably meant here. 

What’s about the following change to the abstract:

Either remove the brackets:

"The link bandwidth utilization is another
   important factor to consider during path computation.“

Or write down what Dhruv actually said:

„The link bandwidth utilization (the actual
   bandwidth used without any reserved bandwidth) is another
   important factor to consider during path computation.“

For other comments, please see may next mail in reply to Dhruv's mail.

Mirja


> Am 15.09.2016 um 18:10 schrieb 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 currentJ
> (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] 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] 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