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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 14 Sep 2016 13:14:02 -0700

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

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

- section 3 could be removed. It didn't really help me and the normative
language here is actually a little bit confusing to me.

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

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

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

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

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

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

- "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?

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

- 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)!

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 15 Sep 2016 05:37:21 +0000

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:[email-masked]] On Behalf Of Mirja Kuehlewind
> Sent: 15 September 2016 01:44
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Mirja Kühlewind's 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 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.
> 

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

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

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

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

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

> Also in the next two sections...

 [Dhruv] Ack. This has been done as part of OPS directorate review by Jouni Korhonen.

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

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

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

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

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

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

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

Thanks again for your review and questions. 

Regards,
Dhruv

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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 15 Sep 2016 14:03:03 +0000

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

> From: iesg [mailto:[email-masked]] On Behalf Of Dhruv Dhody
> Sent: Thursday, September 15, 2016 1:37 AM
> To: Mirja Kuehlewind <[email-masked]>; The IESG <[email-masked]>
> Cc: Dhruv Dhody <[email-masked]>; [email-masked]; draft-ietf-pce-pcep-
> [email-masked]; [email-masked]
> Subject: RE: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pcep-
> service-aware-12: (with COMMENT)
> 
> Hi Mirja,
> 
> seems
>  [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.
> 
> path
>  [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.
> 
> >
> [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.
> 
> delay
> 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.
> 
>  [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.
> 
> > - OLD:
>  [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.
> I have updated the formula to avoid using the term LBU, and instead used
> utilized bandwidth, which I hope would clear up the confusion.
> 
> So when we deduct this from utilized bandwidth, we are left with the
> bandwidth used for the actual forwarding of RSVP-TE LSPs.
> 
>  [Dhruv] The utilization percentage needs to be checked on each candidate
> link during path computation, and that was the reason for the initial wording.
>  [Dhruv] We have followed the general practice done in PCEP. Having BU
> object behave differently from METRIC object doesn’t seem right.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 15 Sep 2016 10:43:06 -0500

Hi, Deborah/Dhruv,

On Thu, Sep 15, 2016 at 9:03 AM, BRUNGARD, DEBORAH A <[email-masked]> wrote:

> 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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 15 Sep 2016 16:10:56 +0000

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:[email-masked]]
Sent: Thursday, September 15, 2016 11:43 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; Mirja Kuehlewind <[email-masked]>; The IESG <[email-masked]>; Dhruv Dhody <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mirja,

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 16 Sep 2016 14:16:22 +0200

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 <[email-masked]>:
> 
> Hi Spencer,
>  
> Now I need to get to my “current” lunch before it’s not currentJ

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 16 Sep 2016 14:39:37 +0200

Hi Dhruv,

please see inline.

> Am 15.09.2016 um 07:37 schrieb Dhruv Dhody <[email-masked]>:
> 
> Hi Mirja,
> 

See my previous mail.

> [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 wo…
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.

> [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 w…

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.

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

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

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

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

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

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

> [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…

>   MUST be discarded.  If the P bit is cleared, the PCE is free to

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

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

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

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 16 Sep 2016 14:43:00 +0000

Hi Mirja, 

See inline...

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: 16 September 2016 17:46
> Cc: Spencer Dawkins at IETF <[email-masked]>; Dhruv Dhody
> <[email-masked]>; [email-masked];
> [email-masked]; Dhruv Dhody <[email-masked]>; [email-masked];
> The IESG <[email-masked]>
> Subject: Re: [Pce] Mirja Kühlewind's No Objection on
> 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.
> 

[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

> > 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.
> >
> > (Thanks for all the interest!) Deborah
> >
> >
> > Cc: Dhruv Dhody <[email-masked]>; Mirja Kuehlewind
> > <[email-masked]>; The IESG <[email-masked]>; Dhruv Dhody
> > <[email-masked]>; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: [Pce] Mirja Kühlewind's No Objection on
> > 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,
> 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.
> >

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 16 Sep 2016 14:44:27 +0000

Hi Mirja, 

Thanks for your further comments and suggested text. Please see inline. 

> Sent: 16 September 2016 18:10
> To: Dhruv Dhody <[email-masked]>
> Cc: The IESG <[email-masked]>; Dhruv Dhody <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> 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.
> >>
> >> Especially the word "current" is irritating as I strongly assume
> >> you'd be interested in something like the average utilization...?
> >>
> >
> bandwidth utilization on the other hand looks at what is happening with
> the traffic.
> >

[Dhruv] Replied in the other 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.
> >>
> >
> 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.
> 
[Dhruv] Done! 
> >> I would assume that the average path delay variation is NOT the sum
> >> of the link variation.
> 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.:
> 
[Dhruv] The maximum bound is the value provided by PCC to PCE and it is PCE that should make sure that the sum of delay variation of the links in the path should not exceed that value.

Instead, I removed the word "average", and simply call it "delay variation of the path". 

   " An implementation,
   therefore, MAY use the sum of the average delay variation of links
   along a path to derive the delay variation of the path.  An
   implementation MAY also use some enhanced composition function for
   computing the delay variation of a path with better accuracy."

> > [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.
> 
[Dhruv] See suggested text above. Which I hope clears this up too. 
> 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.
> 

[Dhruv] "is to be" has been removed while handing Jouni's comment. 

> >
> >> - 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
> > During path computation usage of percentage is better suited and thus
> we termed it differently as LBU and LRBU.
> >
> 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!
> 

[Dhruv] Ack and updated. 

> > - LRBU = ((utilized bandwidth - (residual bandwidth - available
> > bandwidth))/ maximum reservable bandwidth) * 100
> >
> >              =(residual bandwidth - (residual bandwidth - (bandwidth used
> for the actual forwarding of non-RSVP-TE LSPs)))
> 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!
>

[Dhruv] Ack. 
 
> >> I don't think the thing stated in the original sentence is possible
> >> based on the given information in the LBU/LRBU.
> >>
> >
> 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:
> 

[Dhruv] Perfect and updated! 

> 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.
> 
> I really would remove the normative language here as restating normative
> requirements is bad practice. That would be:
> 

[Dhruv] Agree and Updated! 

I have attached the diff from the last version that I sent you for easy review. 

Thanks! 
Dhruv

> >
> >> - 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)!
> >>
> 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
> 
> >
> > <Diff_  draft-ietf-pce-pcep-service-aware-12.txt -
> >
> draft-ietf-pce-pcep-service-aware-13.txt.html><draft-ietf-pce-pcep-ser
> > vice-aware-13.txt><draft-ietf-pce-pcep-service-aware-13.xml>