Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-01.txt

From: [email-masked]
Date: Sat, 10 Oct 2015 12:03:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Performance Metrics Working Group of the IETF.

        Title           : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
        Authors         : Nalini Elkins
                          Robert Hamilton
                          Michael S. Ackermann
	Filename        : draft-ietf-ippm-6man-pdm-option-01.txt
	Pages           : 28
	Date            : 2015-10-10

Abstract:
   To assess performance problems,  measurements based on optional
   sequence numbers and timing may be embedded in each packet.  Such
   measurements may be interpreted in real-time or after the fact. An
   implementation of the existing IPv6 Destination Options extension
   header, the Performance and Diagnostic Metrics (PDM) Destination
   Options extension header as well as the field limits, calculations,
   and usage of the PDM in measurement are included in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Sat, 10 Oct 2015 19:08:11 +0000 (UTC)

IPPM,

We have added two new sections to address the comments from the WG session in Prague:

1.  Comment:  Indicate that PDM will not work when using IPv6 transition technologies

Action: Section 1.6 IPv6 Transition Technologies added.

2.  Comment: Indicate that PDM must be placed BEFORE the ESP header.

Action:  Section 3.3 "Header Placement" revised.   New section 3.4 "Header Placement Using IPSec ESP Mode" added to further clarify header placement.

Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

----- Forwarded Message -----
From: "[email-masked]" <[email-masked]>
To: [email-masked] 
Cc: [email-masked] 
Sent: Saturday, October 10, 2015 12:03 PM
Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-01.txt

Abstract:

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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 31 Oct 2015 22:07:16 -0400

Hi Nalini, Robert and Mike,

> https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-01
Let's discuss this week when we get a chance...

[ACM] First sentence suggestion
1  Background

   To assess performance problems,  measurements based on optional
   sequence numbers and timing may be embedded in each packet.

suggest:
   To assess performance and diagnose problems, measurements based on optional...
                         ^^^^^^^^^^^^^
THEN:
   An
   implementation of the existing IPv6 Destination Options extension
   header, the Performance and Diagnostic Metrics (PDM) Destination
   Options extension header has been proposed in a companion document.
[ACM]
This is all one doc now, right?

[ACM]
In section 1.6, you give one circumstance where the PDM DOH won't work
for the mixed v4 v6 network in transition.  That's a good limitation to 
make clear.
When we discussed the possibility of header extension removal in 
paragraph 4 of 
https://tools.ietf.org/html/draft-morton-ippm-2330-stdform-typep-01#section-3
I think we may have mentioned that DOH might be removed by some intermediate
nodes today, and this seems to be another case where headers might be 
removed. Although this is inconsistent with recommendations in 
https://tools.ietf.org/html/rfc7045
it may be worth mentioning as a possible pit-fall related to early deployment
of IPv6.

[ACM] in
2.1 Round-Trip Delay

   Round-trip *Network* delay is the delay for packet transfer from a
   source host to a destination host and then back to the source host.
   This measurement has been defined, and the advantages and
   disadvantages discussed in "A Round-trip Delay Metric for IPPM"
   [RFC2681].
It would be worthwhile to mention that the RFC 2681 RT delay 
excludes the destination host processing time, which is a quantity
you want to measure, and keep separate from RT delay.

[ACM]
Section 3.3 Header placement
the first bullet is an "OR"

    - Before the upper-layer header or the ESP header.

Then I see the DOH listed twice, but it is portrayed in 
in the figure of Section 3.4 as an option to have
the header in BOTH, 

    * = if present, could be before ESP, after ESP, or both

Suggest to make *both* in these sections consistent.

Al