Re: Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC

["C. M. Heard" <heard@xxxxxxxxx>]

Hello Al,

Apologies for the truncated message ... the full version is available at https://www.ietf.org/mail-archive/web/ippm/current/msg04999.html.  I'll resend off-list shortly. In the meantime, my responses below are marked [cmh]

Mike Heard

On Sun, Apr 15, 2018 at 6:43 AM, MORTON, ALFRED C (AL) <acm@xxxxxxxxxxxxxxxx> wrote:

Thanks for your review, C.M.

 

please see below [acm],

Al

 

 [ non-controversial stuff elided ]

 

Section 3, page 4, third paragraph, says:

 

   [...] For example, the packet length will

   change if IP headers are converted to the alternate version/address

   family, or if optional Extension Headers are added or removed. [...]

 

Adding or removing extension headers contravenes RFC 8200. Since this is just an example, I would recommend deleting the controversial second clause.

[acm]

Understand, see below.

 

Section 4, page 6, last paragraph, and page 7, first paragraph, say:

 

   The topic of IPv6 Extension Headers brings current controversies into

   focus as noted by [RFC6564] and [RFC7045].  However, measurement use

   cases in the context of the IPPM framework like in-situ OAM in

   enterprise environments or IPv6 Performance and Diagnostic Metrics

   (PDM) Destination Option measurements [RFC8250] can benefit from

   inspection, modification, addition or deletion of IPv6 extension

   headers in hosts along the measurement path.

 

   As a particular use case, hosts on the path may store sending and

   intermediate timestamps into dedicated extension headers to support

   measurements, monitoring, auditing, or reproducibility in critical

   environments.  [RFC8250] endorses the use and manipulation of IPv6

   extension headers for measurement purposes, consistent with other

   approved IETF specifications

[acm] 

This is the end-of-message I received, but I imagine you intended to 

point-out that 8200 and 8250 appear to be in conflict over

addition/deletion of extension headers.

From 8200, section 4:

   Extension headers (except for the Hop-by-Hop Options header) are not

   processed, inserted, or deleted by any node along a packet's delivery

   path, until the packet reaches the node (or each of the set of nodes,

   in the case of multicast) identified in the Destination Address field

   of the IPv6 header.

I wonder why RFC 2119 requirement terms were not used to 

express this idea? We certainly have agreements about

requirements language for Standards Track memos in IETF.  

[cmh]

RFC 2119 language is not strictly required, and the 6man WG decided not to introduce it in the transition from 2460 to 8200.

I didn't agree with that decision, but I was "in the rough."

 

RFC8250 does not involve Extension header insertion/deletion

along the path, but other work-in-progress (in-situ OAM) would.

[cmh]

Correct, 8250 does not involve extension header insertion/deletion/modification along the path.

Thus, the wording of the latter two highlighted sentences above needs to be reworked.

The first highlighted sentence is now dated (as predicted by Fred Baker in https://mailarchive.ietf.org/arch/msg/ippm/8sgikiZbSiD4v2VeKK_FA7TkjmM), but there is ongoing discussion in 6man about updating RFC 8200 to permit insertion/deletion/modification of extension headers (other than hop-by-hop options) under certain circumstances. See https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion.

In any case, a measurement framework should be prepared to 

handle some unexpected/discouraged behaviors encountered on the path.

[cmh]

I do not disagree with that; but but might it not be appropriate to change to Section 4, page 7, fifth paragraph, from:

   o  Extension Header insertion or deletion: It is possible that
      Extension Headers could be added to, or removed from the header
      chain.  The resulting packet may be standard-formed, with a
      corresponding Type-P.

to something like:

   o  Extension Header insertion or deletion: Although such behavior is
      not endorsed by current standards, it is possible that Extension
      Headers could be added to, or removed from the header chain.  The

      resulting packet may be standard-formed, with a corresponding
      Type-P.

If that doesn't work for you, perhaps say something to the same effect could be said in the paragraphs at the bottom of page 6 and the top of page 7.

Note that there were comments on PMTUD in the part of the message that you didn't get; hopefully those will get to you in the re-send coming shortly.

Mike Heard