Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-04.txt

From: [email-masked]
Date: Tue, 05 Apr 2016 12:35:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks of the IETF.

        Title           : When to use RFC 6553, 6554 and IPv6-in-IPv6
        Authors         : Maria Ines Robles
                          Michael C. Richardson
                          Pascal Thubert
	Filename        : draft-ietf-roll-useofrplinfo-04.txt
	Pages           : 31
	Date            : 2016-04-05

Abstract:
   This document looks at different data flows through LLN networks
   where RPL is used to establish routing.  The document enumerates the
   cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is
   required.  This analysis provides the basis on which to design
   efficient compression of these headers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-04

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Apr 2016 15:41:22 -0400

> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-04

This diff is the result of discussion with Ines over lunch today as she was
making the slides and validating my adjustments.  Specifically, the table for
storing mode was just slightly tweaked so that it looks better.

The non-storing table was updated to clarify that the destination for the
IPIP is the previous 6LR before the 6LN which does not speak RPL.

Again: my point from before, we can get rid of hop-by-hop IPIP headers by
       changing the Option Type, or by creating some signal that there
       are no non-RPL nodes.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Apr 2016 09:37:12 -0400

> changing the Option Type, or by creating some signal that there

The revised proposal at 6man this morning (not yet in text of a draft) is
that all current Option Types become ignore if node does not understand.
(A note can be configured to understand a HbH and drop it)

This means that we do not need to change our Option Type to get the behaviour
that I think we would like.

It also means that we do not need to remove the RPI header before sending
traffic to the Internet.  This is significant because it means that we do not
need an extra IPIP header for traffic leaving the LLN.
We still need an IPIP (+RPI+ RH3-for-non-storing) for incoming traffic, and
we still want to compress it.

That incoming traffic *COULD* now include an RPI from another LLN, but that's
okay, we probably have to encapsulate in IPIP to add our own RPI.
Could we reuse an RPI that is already there, I'm not sure.

A really important result is that we can remove all cases and consideration
of cases where the target is not known to support RPI.

If this WG agrees with the 6man proposal, I will remove those cases from
useofrpi and explain why.