[Roll] direction of draft-robles-roll-useofrplinfo

[Michael Richardson <[e-mail]>]

You will recall that the ROLL WG was rechartered back in March to include two
new work items:

Work Items:
- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.
- Details about how to compress RFC6553, RFC6554, and IP headers in the
  6LoWPAN adaptation layer context
  (from https://datatracker.ietf.org/wg/roll/charter/ )

Noting a certain lack of enthusiasm to get item one started, yet knowing that we
need to get it very clear, Ines and I wrote draft-robles-roll-useof-rplinfo.

The document is now at:
    https://drive.google.com/file/d/0B8TIw964rTlfcnNpb3pBc2VsSTg/view?usp=sharing
        (you can comment)
    https://github.com/ietf-roll/useofrplinfo (fork it and send pull request)

We anticipate asking the WG to adopt it; we would also like to have help
editing this document, but regardless we should diverge slightly to talk
about conflicts.  As both of your WG chairs are authors, on the advice of
a routing AD, we will be seeking another party to judge consensus, and we
will also need a document shepherd.

Now about, the document, from the table of contents:

  3.  Sample/reference topology
  4.  Example flow from leaf to root  . .
  5.  Example flow from leaf to Internet
  6.  Example flow from leaf to leaf  . .
  7.  Example flow from Internet to leaf
  8.  Example flow from root to leaf  . .

The first thing is that I think we will adopt the numbering for the nodes
that Pascal's document had.

The purpose of having these example flows is to make precise what node
inserts what header, where the headers are removed (and potentially
re-added), and what headers are either modified or untouched during the flow.

Pessimistically, we need all the various headers (RPI, RH3 and IPIP) on every
packet, but actually, that may not always be true.  Getting the rules well
established is important if we are going to be able to compress things well.

Additionally, each flow has potential changes between storing and non-storing
mode.

Questions:
  1) Are the situations where it is okay for RPI information to flow out to
     the Internet?  For instance, in an P2MP situation (such as AMI) where
     the collection point is RPL aware, could we drop the IPIP header
     (5. example), given that the leaf node will insert the RPI, and on
     upwards flows we do not need RH3 headers (for both storing and
     non-storing).

  2) Are there situations, such as leaf to leaf in a non-storing situation,
     where the originating leaf can avoid an IPIP header having to be
     inserted by the Root, by inserting the RH3 header (empty) itself?

     i.e. set Segments Left = 0, but reserve space for them using the ext
     header len.  Then the root could fill them in.

  3) Are there additional situations in which we can or should dispense with
     one or more of these headers?

--
Michael Richardson <[e-mail]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/