Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

From: Qin Wu <[email-masked]>
Date: Fri, 14 Feb 2014 10:44:06 +0000

Hi, authors:
I am assigned Performance Directorate reviewer for this draft.
Here is my review to this draft.

This draft uses the link latency, latency variation and packet loss information for end to end path selection.
The link latency, latency variation and packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and
used to calculate path metrics described in this draft, e.g., P2P latency metric, P2P latency variation metric, packet loss
metric, P2MP latency metric, P2MP latency variation metric.

These calculated path metrics( 6 metrics) are carried in PCEP message using the same Metric Object with different metric type.
The calculated metrics are used as constraint for path computation

In this draft, each calculated metric is discussed in each separate section from metric name, metric description
perspective to measurement unit, calculation method perspective.
IANA is also requested to register these 6 metric types. Therefore I believe this draft conforms to RFC6390 guideline.
However I have a few comments regarding these metrics definitions.
1. Section 4, 2nd paragraph says:
"
   This document defines the following optional types for the METRIC
   object defined in [RFC5440].
"
s/defined in [RFC5440]/defined in section 7.4 of [RFC5440]

2. Section 4.1 says:
"
   Link delay metric is defined in [OSPF-TE-EXPRESS] and
   [ISIS-TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP
   encodes the sum of the link delay metric of all links along a P2P
   Path.  Specifically, extending on the above mentioned terminology:

   - A Link delay metric of link L is denoted D(L).

   - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}.

   * T=13(TBA - IANA): Latency metric
"
For people who are not familiar with Metrics Object Format, it is not easy to figure out what T=13 stands for? Would it be good to add some context text or
Introduce Metric Object format first.

3. Section 4.2 says:
"
   - A Latency variation of link L is denoted DV(L).

   - A P2P latency variation metric for the Path P = function {DV(Lpi),
   (i=1...K)}.
"
Why not sum of latency variation metrics of individual links?

4. Section 4.2 says:
"
Specification of the "Function" used to drive latency variation
metric of a path from latency variation metrics of individual links
along the path is beyond the scope of this document.
"
s/drive/derive

5. Section 4
Section 4.3 says:
"Packet Loss Metric metric type of METRIC Object"
Section 4.2 says:
"P2P latency variation metric type of METRIC
   Object"
For consistency, you may either use "xx Metric metric type" or "xx metric type of Metric Object".

6.Section 4.3 says:
"
   The end to end Packet Loss for the path is represented by this
   metric.

   - A Packet loss of link L is denoted PL(L).

   - A P2P packet loss metric for the Path P = function {PL(Lpi),
   (i=1...K)}.
"
Is function of packet loss metric of individual link same as function of latency variation metric of individual link?
If they are not same, please use different function name, e.g., function a for packet loss, function b for latency variation?

Regards!
-Qin

________________________________

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 14 Feb 2014 09:20:17 -0500

A few additional comments, we can help the authors a bit more
I think, but Qin was on the right track.

Al

Qin wrote:
3. Section 4.2 says:
"

   - A P2P latency variation metric for the Path P = function {DV(Lpi),
   (i=1...K)}.
"
Why not sum of latency variation metrics of individual links?
-------------------------------------------------------

Sum is a rather worst-case approximation of the Path DV.

We have studied these sorts of e2e Path estimates in IPPM.
Packet Delay Variation is the most complex, but a couple of
possibilities for "function" are specified here:
http://tools.ietf.org/html/rfc6049#page-20

Similarly, we have functions, which could be cited as references
in this draft, for loss
http://tools.ietf.org/html/rfc6049#page-18

and for mean delay
http://tools.ietf.org/html/rfc6049#section-4.2

So, no need to leave the "function" unspecified and out of scope,
assuming your loss and delay metric definitions are compatible.

From: pm-dir [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Friday, February 14, 2014 5:44 AM
To: Dhruv Dhody; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Hi, authors:

2. Section 4.1 says:
"

3. Section 4.2 says:
"

4. Section 4.2 says:
"

5. Section 4
Section 4.3 says:

6.Section 4.3 says:
"

Regards!
-Qin

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 14 Feb 2014 18:38:22 +0530

Hi Qin, 

Thanks for your review of our document.  Comments inline and diff file
attached.

I will also get confirmation from co-authors and contributors if they are
okay with these changes.  

From: Qin Wu [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 4:14 PM
To: Dhruv Dhody; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Request for an RFC 6390 review of
draft-ietf-pce-pcep-service-aware-02

Hi, authors:

This draft uses the link latency, latency variation and packet loss
information for end to end path selection. 

The link latency, latency variation and packet loss metrics are defined in
OSPF-TE draft and ISIS-TE draft and 

used to calculate path metrics described in this draft, e.g., P2P latency
metric, P2P latency variation metric, packet loss 

These calculated path metrics( 6 metrics) are carried in PCEP message using
the same Metric Object with different metric type.  

In this draft, each calculated metric is discussed in each separate section
from metric name, metric description 

IANA is also requested to register these 6 metric types. Therefore I believe
this draft conforms to RFC6390 guideline.

"

"

[DhruvDhody>] Okay, But Metric section is 7.8 in RFC5440
http://tools.ietf.org/html/rfc5440#section-7.8 :)

2. Section 4.1 says:

"

"

For people who are not familiar with Metrics Object Format, it is not easy
to figure out what T=13 stands for? Would it be good to add some context
text or

[DhruvDhody>] Done! Check the diff file attached if this is acceptable to
you. 

3. Section 4.2 says:

"

   (i=1...K)}.

"

[DhruvDhody>] Making it a sum and aligning to
http://tools.ietf.org/html/draft-ietf-mpls-te-express-path-00#section-2.1

Is not a bad idea in my opinion. I need to discuss further with my
co-authors, if there is any objection to that. 

4. Section 4.2 says:

"

"

s/drive/derive

[DhruvDhody>] sentence removed. 

5. Section 4

Section 4.3 says:

Section 4.2 says:

   Object"

For consistency, you may either use "xx Metric metric type" or "xx metric
type of Metric Object".

[DhruvDhody>] Done! 

6.Section 4.3 says:

"

   metric.

   (i=1...K)}.

"

Is function of packet loss metric of individual link same as function of
latency variation metric of individual link?

If they are not same, please use different function name, e.g., function a
for packet loss, function b for latency variation?

[DhruvDhody>] I have updated this, please check the diff. 

Regards,

Dhruv

Regards!

-Qin

---

From: Qin Wu <[email-masked]>
Date: Sat, 15 Feb 2014 02:35:54 +0000

Hi, Al:
You raise very good comments for this. Here are a few thoughts below.

Regards!
-Qin

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Al

Qin wrote:
3. Section 4.2 says:
"

[Qin]: Yes, it is a rat hole that needs to be fixed.
Do you know how the function defined in section 6.4.5.1 of RFC6049
Can be applied to this draft and quoted as function of latency variation
For complete path from source to destination.

It seems to me we only know delay variation of each sub path, which is
gathered from link delay variation advertisement defined in
draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each sub path
is millisecond.

Using sum may be the worse case approximation of path DV and cause the granularity
of measurement result very coarse, but the computation overhead
for calculation of path DV can be minimized.
If we use integral function defined in section 6.4.5.1 of RFC6049, definitely we
Can improve granularity of measurement/calculation result but at the cost of
Consuming more computation overhead. So there is tradeoff to pick one or another.

[Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be
cited as reference for this draft.

and for mean delay

[Qin]: Exactly.

Hi, authors:

2. Section 4.1 says:
"

3. Section 4.2 says:
"

4. Section 4.2 says:
"

5. Section 4
Section 4.3 says:

6.Section 4.3 says:
"

Regards!
-Qin

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 15 Feb 2014 08:42:13 -0500

Hi Qin, authors,

I read, in draft-ietf-ospf-te-metric-extensions:
4.3.4<http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-4.3.4>. Delay Variation
   This 24-bit field carries the average link delay variation over a
   configurable interval in micro-seconds, encoded as an integer value.
   When set to 0, it has not been measured. When set to the maximum
   value 16,777,215 (16.777215 sec), then the delay is at least that
   value and may be larger.

So this is an *average* DV, to my surprise,
and therefore the sum function Qin proposed is reasonable.

(it still doesn't say here what form of delay variation has been measured)

However, delay variation is better characterized in summary
statistics which describe the breadth of the DV distribution.
In bimodal delay distributions, the average can be misleading.

But you have what you have in draft-ietf-ospf-te-metric-extensions
for now, and summing averages is an easy problem.  Use RFC6049
for the other metrics, like loss and delay.

regards,
Al

From: Qin Wu [mailto:[email-masked]]
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Hi, Al:

Regards!
-Qin

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Al

Qin wrote:
3. Section 4.2 says:
"

and for mean delay

[Qin]: Exactly.

From: pm-dir [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Friday, February 14, 2014 5:44 AM
To: Dhruv Dhody; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Hi, authors:

2. Section 4.1 says:
"

3. Section 4.2 says:
"

4. Section 4.2 says:
"

5. Section 4
Section 4.3 says:

6.Section 4.3 says:
"

Regards!
-Qin

---

From: Paul Aitken <[email-masked]>
Date: Sat, 15 Feb 2014 22:32:59 +0000

Al, All,

For clarity, it would be better to name this as, "Average Delay 
Variation". Similarly, 4.1 would be clearer as "Average Unidirectional 
Link Delay Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries 
the (metric) over a configurable interval".

Is it important or necessary to convey the configured size of the 
interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 
minutes ago) ?

P.

On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote:
>
> Hi Qin, authors,
>
> I read, in *draft-ietf-ospf-te-metric-extensions*:
>
> *4.3.4* 
> <http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-4.3.4>*. 
> Delay Variation*
>
> So this is an **average** DV, to my surprise,
>
> But you have what you have in *draft-ietf-ospf-te-metric-extensions*
>
> *From:*Qin Wu [mailto:[email-masked]]
> *Sent:* Friday, February 14, 2014 9:36 PM
> *To:* MORTON, ALFRED C (AL); Dhruv Dhody; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [pm-dir] Request for an RFC 6390 review of 
> *From:*MORTON, ALFRED C (AL) [mailto:[email-masked]]
> *Sent:* Friday, February 14, 2014 10:20 PM
> *To:* Qin Wu; Dhruv Dhody; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [pm-dir] Request for an RFC 6390 review of 
> *3. Section 4.2 says:*
> *[Qin]: Yes, it is a rat hole that needs to be fixed.*
>
> *Do you know how the function defined in section 6.4.5.1 of RFC6049*
>
> *Can be applied to this draft and quoted as function of latency variation*
>
> *For complete path from source to destination.*
>
> **
>
> *It seems to me we only know delay variation of each sub path, which is *
>
> *gathered from link delay variation advertisement defined in *
>
> *draft-ietf-ospf-te-metric-extensions. The unit of delay variation of 
> each sub path*
>
> *is millisecond.*
>
> **
>
> *Using sum may be the worse case approximation of path DV and cause 
> the granularity *
>
> *of measurement result very coarse, but the computation overhead*
>
> *for calculation of path DV can be minimized.*
>
> *If we use integral function defined in section 6.4.5.1 of RFC6049, 
> definitely we*
>
> *Can improve granularity of measurement/calculation result but at the 
> cost of*
>
> *Consuming more computation overhead. So there is tradeoff to pick one 
> or another.*
>
> **
>
> *[Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be*
>
> *cited as reference for this draft.*
>
> and for mean delay
>
> *From:*pm-dir [mailto:[email-masked]] *On Behalf Of *Qin Wu
> *Sent:* Friday, February 14, 2014 5:44 AM
> *To:* Dhruv Dhody; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* [pm-dir] Request for an RFC 6390 review of 
> The link latency, latency variation and packet loss metrics are 
> defined in OSPF-TE draft and ISIS-TE draft and
>
> used to calculate path metrics described in this draft, e.g., P2P 
> latency metric, P2P latency variation metric, packet loss
>
> These calculated path metrics( 6 metrics) are carried in PCEP message 
> using the same Metric Object with different metric type.
>
> In this draft, each calculated metric is discussed in each separate 
> section from metric name, metric description
>
> IANA is also requested to register these 6 metric types. Therefore I 
> believe this draft conforms to RFC6390 guideline.
>
> *1. Section 4, 2^nd paragraph says:*
>
> "
>
> *2. Section 4.1 says:*
> For people who are not familiar with Metrics Object Format, it is not 
> easy to figure out what T=13 stands for? Would it be good to add some 
> context text or
>
> **
> **
> *3. Section 4.2 says:*
> *4. Section 4.2 says:*
> *5. Section 4*
> *6.Section 4.3 says:*
> Is function of packet loss metric of individual link same as function 
> of latency variation metric of individual link?
>
> If they are not same, please use different function name, e.g., 
> function a for packet loss, function b for latency variation?
>
> Regards!
>
> -Qin
>
>
>
> _______________________________________________
> pm-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pm-dir

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 16 Feb 2014 08:44:39 -0500

All Paul's suggestions for increasing clarity are fine with me.
Al

From: Paul Aitken [mailto:[email-masked]]
Sent: Saturday, February 15, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Al, All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries the (metric) over a configurable interval".

Is it important or necessary to convey the configured size of the interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ?

P.

regards,
Al

To: MORTON, ALFRED C (AL); Dhruv Dhody; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi, Al:

Regards!
-Qin

Al

Qin wrote:
3. Section 4.2 says:
"

and for mean delay

[Qin]: Exactly.

Hi, authors:

2. Section 4.1 says:
"

3. Section 4.2 says:
"

4. Section 4.2 says:
"

5. Section 4
Section 4.3 says:

6.Section 4.3 says:
"

Regards!
-Qin

pm-dir mailing list

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

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 17 Feb 2014 16:20:56 +0000

Hi:

This is my understanding that we need to just use the baseline IGP drafts for definition of all parameters we are using in this draft. So would it be fair that this draft just puts-in reference for the parameters used and point to IGO (OSPF) doc for the definition. We should not copy any text from IGP drafts or any other RFC (just pointer). That will also improve readability and consistency for this draft.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 17, 2014 10:18 AM
To: "'MORTON, ALFRED C (AL)'" <[email-masked]<mailto:[email-masked]>>, "Paul Aitken (paitken)" <[email-masked]<mailto:[email-masked]>>, 'Qin Wu' <[email-masked]<mailto:[email-masked]>>, zali <[email-masked]<mailto:[email-masked]>>, "George Swallow (swallow)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Vishwas Manral' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Hi All,

The authors are grateful for the comments and have prepared an updated version.

Qin,
Could you have a look and suggest if we have addressed your comments & changes are acceptable to you?

Regarding interval, see my comment inline.

Regards,
Dhruv

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Al, All,

Is it important or necessary to convey the configured size of the interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ?
[DhruvDhody>] The metrics we have in this I.D.  are calculated based on link metrics defined in OSPF-TE draft [1], and is not measured directly.
Therefore the time of the interval is same as link metrics defined in OSPF-TE draft. OSPF-TE draft section 7 discusses this. [2]
We do not see a reason to mention this in the PCE I.D.

[1]http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05
[2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-7

P.

regards,
Al

Hi, Al:

Regards!
-Qin

Al

Qin wrote:
3. Section 4.2 says:
“

”

and for mean delay

[Qin]: Exactly.

Hi, authors:

“
”

2. Section 4.1 says:
“

”

3. Section 4.2 says:
“

”

4. Section 4.2 says:
“
”
s/drive/derive

5. Section 4
Section 4.3 says:
“Packet Loss Metric metric type of METRIC Object”
Section 4.2 says:
“P2P latency variation metric type of METRIC
   Object”
For consistency, you may either use “xx Metric metric type” or “xx metric type of Metric Object”.

6.Section 4.3 says:
“

”

Regards!
-Qin

pm-dir mailing list

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 17 Feb 2014 20:48:06 +0530

Hi All,

The authors are grateful for the comments and have prepared an updated
version.

Qin,

Could you have a look and suggest if we have addressed your comments &
changes are acceptable to you? 

Regards,

Dhruv

From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of
draft-ietf-pce-pcep-service-aware-02

Al

From: Paul Aitken [mailto:[email-masked]] 
Sent: Saturday, February 15, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [pm-dir] Request for an RFC 6390 review of
draft-ietf-pce-pcep-service-aware-02

Al, All,

For clarity, it would be better to name this as, "Average Delay Variation".
Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay
Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries the
(metric) over a configurable interval". 

Is it important or necessary to convey the configured size of the interval
and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago)
?

[DhruvDhody>] The metrics we have in this I.D.  are calculated based on link
metrics defined in OSPF-TE draft [1], and is not measured directly.

Therefore the time of the interval is same as link metrics defined in
OSPF-TE draft. OSPF-TE draft section 7 discusses this. [2]

[1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05

[2]
http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-7

P.

Hi Qin, authors,

<http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-
4.3.4> 4.3.4. Delay Variation

   value and may be larger.

regards,

Al

From: Qin Wu [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of
draft-ietf-pce-pcep-service-aware-02

Hi, Al:

Regards!

-Qin

From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of
draft-ietf-pce-pcep-service-aware-02

Al

Qin wrote:

3. Section 4.2 says:

"

   (i=1...K)}.

"

draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each
sub path

is millisecond.

Using sum may be the worse case approximation of path DV and cause the
granularity 

If we use integral function defined in section 6.4.5.1 of RFC6049,
definitely we

Consuming more computation overhead. So there is tradeoff to pick one or
another.

in this draft, for loss

and for mean delay

[Qin]: Exactly.

Subject: [pm-dir] Request for an RFC 6390 review of

Hi, authors:

"

"

2. Section 4.1 says:

"

"

 

3. Section 4.2 says:

"

   (i=1...K)}.

"

4. Section 4.2 says:

"

"

s/drive/derive

5. Section 4

Section 4.3 says:

Section 4.2 says:

   Object"

6.Section 4.3 says:

"

   metric.

   (i=1...K)}.

"

Regards!

-Qin

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Feb 2014 01:02:09 +0000

Hi, Dhruv:
Thanks for your proposed changes and clarification.
Your proposed changes look acceptable to me.

Regards!
-Qin
From: Dhruv Dhody
Sent: Monday, February 17, 2014 11:18 PM
To: 'MORTON, ALFRED C (AL)'; 'Paul Aitken'; Qin Wu; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Hi All,

Qin,

Regards,
Dhruv

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Al, All,

P.

regards,
Al

Hi, Al:

Regards!
-Qin

Al

Qin wrote:
3. Section 4.2 says:
"

and for mean delay

[Qin]: Exactly.

Hi, authors:

2. Section 4.1 says:
"

3. Section 4.2 says:
"

4. Section 4.2 says:
"

5. Section 4
Section 4.3 says:

6.Section 4.3 says:
"

Regards!
-Qin

pm-dir mailing list

---

From: Paul Aitken <[email-masked]>
Date: Tue, 18 Feb 2014 10:49:46 +0000

The comments below are really applicable to 
draft-ietf-ospf-te-metric-extensions, which pm-dir hasn't been asked to 
review.

Nevertheless, I hope that the authors will consider them useful for the 
next version.

viz:

. clearly indicate that these metrics are averages
. indicate that the configurable interval is specified in section 7.

Thanks,
P.

> *Sent:* Sunday, February 16, 2014 7:15 PM
> *To:* Paul Aitken; Qin Wu; Dhruv Dhody; [email-masked]; 
> *From:*Paul Aitken [mailto:[email-masked]]
> *Sent:* Saturday, February 15, 2014 5:33 PM
> *To:* MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> *Subject:* Re: [pm-dir] Request for an RFC 6390 review of 
> interval and the time of the interval (ie, whether it was 5ms, 5s, or 
> 5 minutes ago) ?
>
> */[DhruvDhody>] The metrics we have in this I.D.  are calculated based 
> on link metrics defined in OSPF-TE draft [1], and is not measured 
> directly./*
>
> */Therefore the time of the interval is same as link metrics defined 
> in OSPF-TE draft. OSPF-TE draft section 7 discusses this. [2]/*
>
> */We do not see a reason to mention this in the PCE I.D./*
>
>
> *//*[1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05
>
> [2] 
>     *To:* MORTON, ALFRED C (AL); Dhruv Dhody; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *draft-ietf-ospf-te-metric-extensions. The unit of delay variation
>     of each sub path*
>
>     *is millisecond.*
>
>     **
>
>     *Using sum may be the worse case approximation of path DV and
>     cause the granularity *
>
>     *If we use integral function defined in section 6.4.5.1 of
>     RFC6049, definitely we*
>
>     *Can improve granularity of measurement/calculation result but at
>     the cost of*
>
>     *Consuming more computation overhead. So there is tradeoff to pick
>     one or another.*
>
>     **
>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     This draft uses the link latency, latency variation and packet
>     loss information for end to end path selection.
>
>     These calculated path metrics( 6 metrics) are carried in PCEP
>     message using the same Metric Object with different metric type.
>
>     In this draft, each calculated metric is discussed in each
>     separate section from metric name, metric description
>
>     IANA is also requested to register these 6 metric types. Therefore
>     I believe this draft conforms to RFC6390 guideline.
>
>     For people who are not familiar with Metrics Object Format, it is
>     not easy to figure out what T=13 stands for? Would it be good to
>     add some context text or
>
>     Is function of packet loss metric of individual link same as
>     function of latency variation metric of individual link?
>
>     [email-masked]  <mailto:[email-masked]>
>