Subject: [ippm] Fwd: New Version Notification for draft-ietf-ippm-2330-ipv6-02.txt

From: Joachim Fabini <[email-masked]>
Date: Wed, 11 Oct 2017 10:18:25 +0200

Dear ippm, dear ippm chairs,

as agreed at the IETF meeting in Prague we have updated and submitted
version 2 of draft-ietf-ippm-2330-ipv6. From the authors' perspective
the document is now ready for starting wglc.

Summary of changes:
The new version updates the title ("IPv6, IPv4 and Coexistence Updates
for IPPM's Active Metric Framework") to reflect the enlarged draft
scope. Main focus has been on the four topics/decisions that we
presented at the Prague Meeting:
1. Fragement handling (no fragmentation allowed for v4 and for v6)
2. Header compression, 6LoWPAN: out of scope (requires substantial work
in defining std-formed packet etc - should be discussed in own draft if
needed).
3. Deprecated minimal std-formed packet for v4 and v6 (not used nor
referenced)
4. IPv6 Extension Headers and measurements. The PDM options RFC is a
first use case, in-situ OAM will follow. Even if there are controversal
discussions on EH manipulation in intermediate nodes, these can
beneficially support measurements.

Please review and provide feedback,

thanks and best regards
Joachim

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-ippm-2330-ipv6-02.txt
Date: Wed, 11 Oct 2017 00:44:29 -0700
From: [email-masked]
To: [email-masked], Michael S. Ackermann <[email-masked]>,
Vinayak Hegde <[email-masked]>, Joachim Fabini
<[email-masked]>,  [email-masked]
<[email-masked]>, Nalini Elkins
<[email-masked]>, Al Morton <[email-masked]>,
Joachim Fabini <[email-masked]>

A new version of I-D, draft-ietf-ippm-2330-ipv6-02.txt
has been successfully submitted by Joachim Fabini and posted to the
IETF repository.

Name:		draft-ietf-ippm-2330-ipv6
Revision:	02
Title:		IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric
Framework
Document date:	2017-10-10
Group:		ippm
Pages:		14
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ippm-2330-ipv6-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-2330-ipv6-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2330-ipv6-02

Abstract:
   This memo updates the IP Performance Metrics (IPPM) Framework RFC
   2330 with new considerations for measurement methodology and testing.
   It updates the definition of standard-formed packets in RFC 2330 to
   include IPv6 packets, deprecates the definition of minimum standard-
   formed packet, and augments distinguishing aspects of packets,
   referred to as Type-P for test packets in RFC 2330.  This memo
   identifies that IPv4-IPv6 co-existence can challenge measurements
   within the scope of the IPPM Framework.  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).

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.

The IETF Secretariat

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Oct 2017 09:05:22 -0500

Just checking ...

On Wed, Oct 11, 2017 at 3:18 AM, Joachim Fabini <[email-masked]
> wrote:

> in defining std-formed packet etc - should be discussed in own draft if

I don't disagree with Joachim, but do wonder if there are 6LowPAN people on
this mailing list who will see this and think about whether this is
important to them, or if letting 6lo know and inviting them to think about
working on a 6LowPAN-specific draft would be a good thing to do.

Spencer

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

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 12 Oct 2017 16:31:37 +0200

Hi Spencer, ippm

thank you for your feedback. Hosting 6LoWPAN under the IPPM framework
umbrella seems to not be that easy and perhaps close to the limits of
the ippm charter. Please find some detailed reasoning inline below, it
may raise controversial discussions. The statements below reflect my
current personal view on the 6LoWPAN topic. Still, imo it's worth
reviewing and sketching down some potential challenges before investing
effort into elaborating technical solutions that eventually may not fit
or break existing work.

On 2017-10-11 16:05, Spencer Dawkins at IETF wrote:
> Just checking ...
> 
> On Wed, Oct 11, 2017 at 3:18 AM, Joachim Fabini
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I don't disagree with Joachim, but do wonder if there are 6LowPAN people
> on this mailing list who will see this and think about whether this is
> important to them, or if letting 6lo know and inviting them to think
> about working on a 6LowPAN-specific draft would be a good thing to do.

Good point. I'd like to spend some words on the background and on the
reasoning why the IPv6 update draft adopts the current position wrt
6LoWPAN. Mandatory disclaimer: I read through the relevant 6LoWPAN RFCs
and tried to get the essence - but have no practical experience (and
little incentive) in LoWPAN. So it might be that some assumptions are
wrong. Your proposal to invite 6LoWPAN experts is therefore a good
option and the right way to go. Any volunteers around?

Seen from the IPPM framework perspective, the main problem with 6LoWPAN
packets is that they don't meet the most basic prerequisites that the
IPPM framework relies on (std-formed packet). In particular there is no
source and destination IP in any packet. It may be also an omission of
RFC2330 and all derived metrics, but "std-formed packet" in RFC2330 does
actually/implicitly imply "std-formed _IP(v4)_ packet". And it's not
just the framework: IPPM's associated metric definitions also explicitly
and repeatedly rely on the existence of IP addresses in _any_
measurement packet.

Summarizing what we have discussed so far in ippm meetings: measurement
support for 6LoWPAN imo goes far beyond the targets of the IPPM
framework and the IPv6 update draft. I see three main questions that 6lo
(with ippm support) might consider:
1. Is there a need for such a measurement framework in the 6LoWPAN context?
2. If answer to 1 is yes: Can 6LoWPAN be fitted into the RFC2330+updates
IPPM framework? Is there substantial overlapping in the objectives to
justify integration of 6LoWPAN with the IPPM framework?
3. If answer to 2 is yes: which are the consequences of doing this
integration? Metric definitions in ippm RFCs (RTD, OWD, ...) explicitly
depend on source and destination IP addresses in any packet (relying on
the std-formed packet requirement in 2330). Unless all metrics are
rewritten to solve this shortcoming, metric applicability is limited to
IPv6 measurements between (fully IPv6 capable) 6LoWPAN-IPv6 gateway
nodes only - and these measurements are (imo) anyhow within the scope of
the IPPM framework after approval of the IPv6 update draft.

If needed, an own measurement framework for 6LoWPAN could be a solution,
some parts of it aligned to the main ippm framework. My feeling is that
the prerequisites/objectives/metrics/methodologies of 6LoWPAN
measurements may differ from the ones of the ippm framework.

Becoming philosophical, the naming of IPPM implies that it's an _IP_
Performance Metrics framework. And my perception is that 6LoWPAN differs
semantically from IP-layer protocols - it's a L2-L3 shim/adaptation
layer below and aside IPv6 that is supposed to enable IPv6
transport/tunneling on top of L1/L2 protocols.

The academic solution to this problem is a new "Meta" Network
Performance Metrics Framework. I.e., write a new draft that defines an
abstract template NetworkPerformanceMetricFramework<network protocol>.
<Network protocol> must define and encapsulate abstract concepts for
nodes, addressing, routing, fragments, etc. that all derived metrics
must use and rely on - instead of terms like, e.g., hosts, IP addresses,
etc. that RFC2330 currently uses.

The instantiation of the meta framework for <IPv4> would be equivalent
to today's RFC2330 framework. In addition we could instantiate this
template for <IPv6>, <6LoWPAN>, etc., too.

But even if I like this theoretical concept, the associated effort is
enormous. It's eventually a cold reset, meaning that there's a need to
rewrite, abstract and "templateize" the framework RFC along with all
IPPM-associated metric definition RFCs, too. I doubt that a) we can find
generic abstractions that cover a majority of existing network protocols
and b) the result is worth the invested effort. It will get very complex
and risks that nobody uses it.

To conclude: we spent substantial time reasoning about options for
hosting 6LoWPAN below the IPPM framework umbrella, and our conclusion
was that 6LoWPAN misses (too) many of the prerequisites that RFC2330
mandates. Taken together these findings recommend that measurement
support for 6LoWPAN has little in common with the submitted RFC2330-IPv6
update draft. This was the main reason why the draft considers 6LoWPAN
to be out of its scope.

Opinions and feedback warmly welcome.

Thanks,
Joachim

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sat, 14 Oct 2017 21:43:33 +0200

Greetings, all,

Let's go ahead and consider WGLC to have started for this draft with Joachim's message, then, to end at the IPPM meeting at IETF 100 in Singapore, on 01:00 UTC Monday 13 November. As Joachim says, please review and provide feedback to the WG at [email-masked].

Many thanks, best regards,

Brian (as IPPM co-chair)

> On 11 Oct 2017, at 10:18, Joachim Fabini <[email-masked]> wrote:
>