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

["Zafar Ali (zali)" <[e-mail]>]

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: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 17, 2014 10:18 AM
To: "'MORTON, ALFRED C (AL)'" <[e-mail]<mailto:[e-mail]>>, "Paul Aitken (paitken)" <[e-mail]<mailto:[e-mail]>>, 'Qin Wu' <[e-mail]<mailto:[e-mail]>>, zali <[e-mail]<mailto:[e-mail]>>, "George Swallow (swallow)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Vishwas Manral' <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

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

From: Paul Aitken [mailto:[e-mail]]
Sent: Saturday, February 15, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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]
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.


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
   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:[e-mail]]
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

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

Regards!
-Qin

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

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

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

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


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

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

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.

[Qin]: Exactly.



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

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







_______________________________________________

pm-dir mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/pm-dir