> -----Original Message----- > From: Tom Herbert [mailto:tom@xxxxxxxxxxxxxxx] > Sent: Sunday, April 15, 2018 12:16 PM > To: MORTON, ALFRED C (AL) <acm@xxxxxxxxxxxxxxxx> > Cc: C. M. Heard <heard@xxxxxxxxx>; IETF <ietf@xxxxxxxx>; 6man > <ipv6@xxxxxxxx>; IPPM <ippm@xxxxxxxx> > 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 > > 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 > > > > > > > > From: C. M. Heard [mailto:heard@xxxxxxxxx] > > Sent: Saturday, April 14, 2018 2:54 PM > > To: IETF <ietf@xxxxxxxx> > > Cc: IPPM <ippm@xxxxxxxx>; 6man <ipv6@xxxxxxxx> > > 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 > > > > > > > > Greetings, > > > > > > > > I have some last call comments on this document. Most (but not all) > focus on > > aspects that do not respect RFC 8200 and RFC 8201. > > > > > > > > The Abstract says: > > > > > > > > [...] Exemplary use cases include, > > > > but are not limited to IPv4-IPv6 translation, NAT, protocol > > > > encapsulation, IPv6 header compression, or use of IPv6 over Low-Power > > > > Wireless Area Networks (6LoWPAN). > > > > > > > > These last two use cases, however, are explicitly excluded in Section 4: > > > > > > > > [...] Because of these reasons we > > > > consider ROHC and 6LowPAN packets to be out of the scope of this > > > > document. > > > > > > > > On that basis, it seems that the last two use cases in the Abstract > should > > be removed. Other places in the draft that IPv6 header compression also > need > > to be looked at. > > > > [acm] > > > > Clarified as follows: > > > > IPv6 header compression and use of IPv6 over > > > > Low-Power Wireless Area Networks (6LoWPAN) are > > > > considered and excluded from the standard-formed packet evaluation. > > > > > > > > and later: > > > > Because of these reasons we consider ROHC and > > > > 6LowPAN packets to be out of the scope for the > > > > standard-formed packet evaluation. > > > > > > > > Section 3, page 3, next to last paragraph, has a reference "Diffserv > > [RFC2780]" -- shouldn't that be "Diffserv [RFC2474]"? > > > > [acm] > > > > yes, 2474 was intended, thanks. > > > > > > > > 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. > > > > > > > > RFC8250 does not involve Extension header insertion/deletion > > > > along the path, but other work-in-progress (in-situ OAM) would. > > > > > > > > In any case, a measurement framework should be prepared to > > > > handle some unexpected/discouraged behaviors encountered on the path. > > > > Alfred, > > That is not what this draft is doing. It is advocating header > extension insertion even though that is contrary to RFC8220. (it is > also advocating processing and modification or destination option by > middleboxes which is also contrary to RFC8200). From the draft: > > "Destination Option measurements [RFC8250] can benefit from > inspection, modification, addition or deletion of IPv6 extension > headers in hosts along the measurement path." > > That ignores the negative protocol implications of extension header > insertion. draft-voyer-6man-extension-header-insertion proposed > updating RFC8200 to allow extension header insertion. The draft got > significant push back and in the 6man discussion a list of problem > with extension header were enumerated. AFAICT the authors of that > draft haven't provided answers to any of the issues yet. > > Tom > [acm] You've cited a sentence fragment above, Tom. 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. Since PDM / RFC8250 exclusively defines measurement based on DOH, it is a bit out of place with " ...modification, addition or deletion of IPv6 extension headers..." (inspection was a possibility, but not discussed in RFC8250) We are proposing to delete PDM/8250 from the sentence: 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. please call me Al, everyone else does
