Minutes for ROLL at interim-2015-roll-1
minutes-interim-2015-roll-1-1

This is the ROLL 2015-02-10 Virtual Interim meeting notes.
(PLEASE SET YOUR NAME IN THE UPPER RIGHT CORNER, WHERE THERE IS A PERSON ICON)
{always good to have an anonymous observer: please make you don't type anything
here[]}

Slides are at:
    http://www.sandelman.ca/SSW/ietf/roll/
or: http://www.ietf.org/proceedings/interim/2015/02/10/roll/proceedings.html

JITSI URL is: https://jitsi.tools.ietf.org/Roll20150210VirtualInterim
I am also in the ROLL jabber conference.

== Time in EDT ==

Presenter: Ralph Droms, Thank you very much Ralph!

Present:
   Michael Richardson
Xavier Vilajosana
Robles Ines
Cenk Gündoğan
Robert Cragie
Pascal Thubert
Gabriel Montenegro
Anon> Simon
Yusuke Doi (etherpad only)
Ralph Droms
Thomas Watteyne

Okay, we have started at 10:15, with Ralph leading.

1. Agenda bashing
2. Goals and desired outcomes for this meeting
3. Cover origin of problem: how did we get here
a. 6tisch requirements for minimal
b. 6man review of flow label
c. 6lo review of NHC
d. publication of dispatch header solution
4. Architectural deep dive of proposals on the table

Goals

 Michael: Note well,
 Ralph: Agenda,develop a strategy to go forward what we think that it is better.
which working group should handle this.

Comments on agenda?

Slide 5: Goal
 - what process do we want to follow?
   Outcome: last call on 6tisch tsch,
   which WG, how much do we try to compress, effort to get the spec published,
   how quick we can do that

Slide 8: firs
     3 efforts, flow label, NHC for RPI only, and NHC+IPinIP+RH using a dispatch
discussion about choosing a mechanism for the IETF 93 Interop 6tisch.
     ETSI Plugtest: Should we encourage implementations to try more than one
     proposal?

Slide 9: Discussion with Brian Haberman

Slide 10 Problem statement
   RPL add 3 artifacts
   Pascal: discussion whether put the information in the specs, it should be
   there. Gabriel: had considered deprecating RPI?
    Pascal: answering  -- - RPI could be replaced with Flow-Label, RPI and RH3
    are not mutually exclusive, but RPI is critical for storing mode, while RH3
    is critical for non-storing mode.  One can sometimes omit one or the other,
    but in general you may need one or both.

Slide 11:
    RPL needs RPI, that's a mandatory component of the design.
    discussion about overhead....
    headers can be modified en-route.
    Overhead can be significant, 8 bytes for the RPI.
    Addition and deletion requires IP in IP encaps. Because IPv6 rules that
    headers cannot be added or deleted on the way.

SLide 12: IP-in-IP encapsulation

   Ralph: uncompressed packet, packet come from the root, from inside-outside
   you should use IP-in-Ip [Dispatch draft] Ralph: discussion when IP-in-IP is
   necessary mcr asks if the originating node in the LLN can insert the RH3,
   such that the root doesn't need to add it, but Pascal points out that we
   wouldn't know how big an RH3 to add?

Slide 13: problem with RH3

Ralph: Rules should be written down, seems not to be included.
Consensus about minimu conclusion, about RH3, we need to add it
Pusshing this off
mcr: what is the roll packet structure up/down when 6lowpan is not available
pascal: we have to find one or two cases for that
Thomas: specify cases is important for implementations.
Xavi: agree with more details when use IP-in-IP
Ralph: Rules are not completed, need to reflect what it is relevant in an
architechtural description. mcr: it is necessary have a distintion between LLN
and DODAG, help to clarify when it is inside or outside, different header
requirements. Pascal: to define how we compress.

{mcr: comment for ETSI plugfest. We should do an interop test with 6lowpan
turned off...} {mcr: do a set of slides explaining all of the combinations of
add/remove, storing/non-storing and talk about this at 6man}miXnimu

Ralph: Partial compression
IP-in-IP encapsulation need define inside

An attempt to show how you use RPI, RH3 and IP-in-IP for traffic within a LLN

1. [RH] -R-> [RR] -R-> [RR] -R-> [R] -3-> [RR] -3-> [RR] -3-> [RH]
2. [RH] IR-> [RR] IR-> [RR] IR-> [R] I3-> [RR] I3-> [RR] ---> [ H]
3. [ H] ---> [RR] IR-> [RR] IR-> [R] I3-> [RR] I3-> [RR] ---> [RH]
4. [ H] ---> [RR] IR-> [RR] IR-> [R] I3-> [RR] I3-> [RR] ---> [ H]

I - IP-in-IP
R - RPI option
3 - RH3 header

[RH] - RPL-aware Host
[ H] - Host not RPL-aware
[RR] - RPL Router
[R]  - DODAG Root

1. Destination is in LLN and all hosts are RPL-aware so no need for IP-in-IP
2. Destination is in LLN but it is not known is all hosts are RPL aware.
IP-in-IP used as unknown. 3. Destination is in LLN. First router adds IP-in-IP.
Final router always removes encapsulation before forwarding to destination 4.
Same as 3

Note the assumption above is that the source-routed packets from the Root do
not contain RPI option.

Slide 14: History

Architechture discussion with 6man chairs, flow label not good solution, not
compress RH3, not compress IP--in-IP encapsulation

Slide 15:  Proposal on the table

    Ralph: NHC not compress RH3, not got consensus. Dispatch, cover all the
    compressions, RIP, RH3, IP-in-IP

    Pascal described the situation mentioned in the MLs

SLIDE 18: Current base solution by mcr

   Mcr explain the structure, is the order correct?
   Thomas and Ralph agrees that this is one of the possile Frames

   Ralph: we need to have IP-in-Ip encapsulation

   Discussion about 6553, 6554, 6282, need more detail to be written to
   understand the architechture

SLide 19: FLow label approach, skip

  Xavi: RFC 6282, problem with extension header follow by hbh and udp header, u
  can not compress it, the extension header has a next header field, after htis
  field use a nhc, does it use rpi header? Pascal: it is out of scope of the
  meeting for today, we can discuss in the ML. we dont have time unfortunately
  for that. Mcr.: from 6282 interpreted compress extension header, nhc header
  can be used for it. next header is compressed. it is unclear why you can do
  it, but you can do it.

Slide 20: NHC Solution

Mcr: rfc no so clear, hard to do the diagram, nhc only will compress RPI

SLide 21: Dispatch approach

Mcr: Diagram showing all the compressed features

     other approach? whichh would be best solution?

    we will have more header to compress, we have to be clear that we are not
    duplicating the mesh header, diagram based on the draft, it is ok.

Robert: use 1011xxxx for mesh under...

In summary, the "half" solution is to not use dispatch code 1011xxxx. This is
the dispatch code for a mesh header using 16-bit V and F addresses, which is
the most likely used case (and I am aware is currently being used by an SDO in
a draft specification, irrespective of who else may be using it). The rationale
is that it is unlikely that you would mix 16 and 64 bit addresses in the mesh
header (VF bits 01 and 10) and using 64 bits for both is costly (VF bits 00).

The impact on draft-thubert-6lo-routing-dispatch would be to make the maximum
length in the length field in the elective format half what it currently is. So
the dispatch codes would look like:

Critical - as is:
100xxxxx

Elective - max. length is half what it currently is:
1010xxxx

RFC4944 dispatch code retained:
1011xxxx

Skip slides 22 to 31, directly go to slide 32

Slide 32: Why not NHC ++

   Pascal: Code point starvation, code base, separate routing

      why RPL? if in the future there is another routing protocol

      Legacy notes, request to make it general
,
      6775-6lowpanND. rework to include bit about whether or knows 6LoRH.

      how we compress RPL artifact?

  Ralph gives a summary of the discussion until now, work to do: when use the
  compression, and consensus that the compression is necessary

        combine 6282 and 4944 and do a new work, to define Iot in TCP headers?

        discussion about mesh header type, what should be defined

       NHC++ draft To be reviewed by SDOs and WG for an opinion, we need
       comments, since we need consensus on this topic

       Need a document that mention what options are on the table, so the
       document can answer the questions whay and when we need this option

  Ralph:
       Three questions:
         1- Where we need to have the discussion?

         2- Which WGs goes to?

         3- Which SDOs?

  make sure that we have a document with the solution to get the rough
  consensus, Need Int area AD are necessary to help to decide if it should be
  managed at 6lo.

  ROLL objected that it is not in the charter, this topic is wider, cover
  several WGs,.

  [ALvaro had connection problems to connect].

Pascal:  Decision, do a document with the description of general implication. A
document is needed telling about the use of mesh header whean it is good.

            we should work with Brian

TODO: make list of questions for Liaison... interaction with ADs needed. Ted
(6tisch).

Where should this work take place? as the compression takes place, it should
take 6lo, if the AD decide it is need for ROLL, it is ok.

Ralph: since ROLL Is closing, it would be good to handle this in 6lo

Gabriel: there are two components to the proposed work: general 6lo
implications either in the NHC+ case or even more so in the dispatch case. so
either way 6lo will be involved. given that the ROLL WG will be shutting down,
it might be practical for 6lo to also do the roll-specific part of the work
(the compression schemes).

Xavi: for minimal, it is there acctually, not compressing the extension header
it is fine, should it be NHC solution? 6554 , USING hbh Header. For Interop
(Slide 39) would be used the current RFCs: 6282, 6553 and 6554, uncompressed
version of rh3

RobertCragie: In ZigBee IP, we used RFC2473 for guidance wrt. IP-in-IP usage

Action items:

    mcr: Write a document that get NHC++ with a clear description, document
    how/when the headers are used and,  present summary at 6lo. TODO: make list
    of questions for Liaison... interaction with ADs needed. Ted (6tisch). Ask
    to ADs which would be the correct WG to handle this