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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Mike, Please see in-line replies,
Al

From: C. M. Heard [mailto:[e-mail]]
Sent: Sunday, April 15, 2018 11:56 AM
To: MORTON, ALFRED C (AL) <[e-mail]>
Cc: IETF <[e-mail]>; IPPM <[e-mail]>; 6man <[e-mail]>
Subject: Re: Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC

Hello Al,

Apologies for the truncated message ... the full version is available at https://www.ietf.org/mail-archive/web/ippm/current/msg04999.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_ippm_current_msg04999.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2J2Uwt4fnAeyqXqxbWRacD0soZcfUMDCm3bv_ySNZ9w&s=Hw-I-LklaEoa82ghk2Aqo5L0sh0Wv-dqicd6ajKCQ4g&e=>.  I'll resend off-list shortly. In the meantime, my responses below are marked [cmh]
[acm]
thanks! it was obvious the end was missing...
I’ve appended your PMTUD comments in this message,
at the end (allegedly, we’ll see if they get through).


Mike Heard
…

 [ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6564&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=qQyZYT0zxt-ClqRU8hIUUNYk5xi5rQvBozAWxjm67os&e=>] and [RFC7045<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7045&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=9I656AjTSjYpQlMstCRImNUaZvenm4kPNq_rI7-VZAg&e=>].  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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8250&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=tw0fik0bS0uC_ifn0S1ue66X-bs70H7Da0xHoQ2ckAA&e=>] 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8250&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=Yk9GCxmytKBlMMeadFP5mNWDshrNtD3ur_Qg-wMX_ts&s=tw0fik0bS0uC_ifn0S1ue66X-bs70H7Da0xHoQ2ckAA&e=>] 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."
[acm]
That’s heavy baggage 6man will have to carry, IMO.
“are not” doesn’t translate to a requirement in any SDO I know.


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.
[acm]
I discussed this at length with co-authors, and arrived at
a tighter wording. We simply delete the PDM citation in the 2nd sentence,
and then we refer to the chartered work on in-situ OAM only:

   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 [ref] in
   enterprise environments can benefit from
   inspection, modification, addition or deletion of IPv6 extension
   headers in hosts along the measurement path.

We will also delete the first sentence in the second paragraph above,
and delete the words “and manipulation”:

   [RFC8250] endorses the use of IPv6 extension headers for
    measurement purposes, consistent with other approved IETF specifications.

The first highlighted sentence is now dated (as predicted by Fred Baker in https://mailarchive.ietf.org/arch/msg/ippm/8sgikiZbSiD4v2VeKK_FA7TkjmM<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ippm_8sgikiZbSiD4v2VeKK-5FFA7TkjmM&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2J2Uwt4fnAeyqXqxbWRacD0soZcfUMDCm3bv_ySNZ9w&s=y3wSRgv_Y4EZ5aBh6uUbxxRTTMcHDpuIYw2nfcWcH0Y&e=>), 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dvoyer-2D6man-2Dextension-2Dheader-2Dinsertion&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=2J2Uwt4fnAeyqXqxbWRacD0soZcfUMDCm3bv_ySNZ9w&s=15z5qksVffY_75SBOZfwpw76NvzJpu18E9LWFvNillM&e=>.
[acm]
Let me know when there is a consensus call,
I will stand with you for using 2119 modal verbs
in the update...


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.
[acm]
Your text suggestion WFM, it’s in our working copy now.

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

[ ...  truncated portion follows …]

Section 4, page 7, next-to-last paragraph says:


   [...] Path MTU Discovery

   for IP version 6 (PMTUD, [RFC8201<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8201&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=QmkalCghj2UWXAYbUNBvVzmVYsjZz3QCRNMcCapKLHI&s=wuYf87r5Jd9R1REA97G2-ftjyVl77Myo6qmYQAHE4JU&e=>]) or Packetization Layer Path MTU

   Discovery (PLPMTUD, [RFC4821<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4821&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=QmkalCghj2UWXAYbUNBvVzmVYsjZz3QCRNMcCapKLHI&s=xTmoRZSTUrTKeA0f9Y_gPjyRuOeOQEPtPe2blgphY40&e=>]) is recommended to prevent

   fragmentation (or ICMP error messages) as a result of IPv6 extension

   header manipulation.

The trailing clause "(or ICMP error messages) as a result of IPv6 extension header manipulation" should be removed, as it is just plain wrong. PMTUD relies on ICMP Packet Too Big messages for proper operation, and in-flight increases in packet length due to insertion of extension headers actually break PTMTUD.

[acm]
Your deletion WFM, it’s in our working copy now.


Section 5, page 8, next-to-last paragraph says:


   o  Modification or addition of headers or header field values in

      intermediate nodes.  As noted in Section 4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2D2330-2Dipv6-2D04-23section-2D4&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=QmkalCghj2UWXAYbUNBvVzmVYsjZz3QCRNMcCapKLHI&s=OmLE-PPyxr3OLg9q10BoDE4yGhg_E_PNGhibcCMmWWk&e=> for IPv6 extension

      header manipulation, NAT, IPv4-IPv6 transitioning or IPv6 header

      compression mechanisms may result in changes of the measurement

      packets' Type-P, too.  Consequently, hosts along the measurement

      path may treat packets differently because of the Type-P

      modification.  Measurements at observation points along the path

      may also need extra context to uniquely identify a packet.

If the changes I recommend above are implemented, it will be necessary to remove the clause "As noted in Section 4 for IPv6 extension header manipulation,"

[acm]
again WFM, Thanks.


Mike Heard