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

[Joachim Fabini <[e-mail]>]

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
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     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).
> 
> 
> 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