Subject: [6tisch] About: virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Feb 2015 15:12:42 +0000

Dear all:

The first plugtest is being defined now. Unless we wait to uncover the issues and suffer at the test, we need to agree on what the frames will be.

The interim discussion pointed out that IPv6 –and the specs that went through 6MAN- expects the addition on IPinIP when headers have to be stripped or added by an intermediate router.

ROLL should produce rapidly a spec that disambiguates the frame content in various steps of storing and non-storing. 

It must be noted that there is no possible RFC 6282 compression after a RH3 or a RPI HbH with the existing specs since these are not compressed. So IPinIP to add/remove RH3 or RPI basically prevents 6lowpan compression of the inner packet. Robert pointed out that ZibgeeIP has addressed this issue and we expect

Nevertheless, my understanding is that most implementation never do IPinIP, but rather reshuffle the headers. It will probably take time till ROLL comes back with the exact frame layouts as IPv6 would expect them. It is still unclear what the compression will be since the reuse of the ‘10’ mesh-under dispatch raises political concerns.

So what do we do for the plugtest? Out of my hat I see the following possibilities:

a)      Document our own layouts in storing and non-storing, bypassing 6MAN for this round, no IPinIP

b)      Follow the ZigbeeIP specs, whatever was done and tested there, and try to standardize it at ROLL

c)      Wait for ROLL and implement their flows - compressing only the encapsulating IP header in case of IPinIP

d)      Implement what we have on the table, either FL, NHC, 6LoRH or a combination thereof, to get implementation feedback

e)       ?

Questions arise :

- to implementers: what’s doable pragmatically by Prage time?

- all: advice / comments?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Ines Robles
Sent: mercredi 11 février 2015 02:42
To: roll
Cc: Adrian Farrel; [email-masked]; [email-masked]; Brian Haberman; [email-masked] WG
Subject: Re: [6tisch] [Roll] virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC

Hello,

Many thanks to Ralph for being the presenter and all the participants.

Please find a draft of the minutes here: http://www.ietf.org/proceedings/interim/2015/02/10/roll/minutes/minutes-interim-2015-roll-1

Note that it could be updated in the following days.

Cheers,

Michael and Ines.

2015-02-10 10:19 GMT+02:00 Ines Robles <[email-masked]>:

Hello,

Please find an updated slides at http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-3.pdf

Thanks,

2015-02-09 19:00 GMT+02:00 Ines Robles <[email-masked]>:

Hello,

This is a reminder of the ROLL Interim meeting tomorrow.

Please find a draft of the slides here http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-1.pdf 

We will use JITSI for audio, video and slides, with the following URL:
     https://jitsi.tools.ietf.org/Roll20150210VirtualInterim

Thank you very much,

Michael and Ines.

2015-01-16 0:00 GMT+02:00 Michael Richardson <[email-masked]>:

In accordance with: https://www.ietf.org/iesg/statement/interim-meetings.html
the ROLL Working Group Chairs are announcing a virtual interim meeting for
February 10, 2015, from 15:00 UTC to 18:00 UTC.
      (please see: http://goo.gl/NVefsy to convert the time)

The very draft agenda is in development, and can be seen at:
  http://www.ietf.org/proceedings/interim/2015/02/10/roll/agenda/agenda-interim-2015-roll-1

The goal of this interim meeting is to do a deep technical dive into the
different ways of optimizing the byte/power cost of the RFC6553 (RPI) and
RFC6554 (RH3) options.  This could involve compression or recoding, or???
We invite submissions on this.  Please post your -00 draft by January 23 if
possible, or point us at your other drafts.

We will use JITSI for audio, video and slides, with the following URL:
     https://jitsi.tools.ietf.org/Roll20150210VirtualInterim
  Participants are encouraged to visit this URL in advance to verify that
  it works for them.  If you need another participant to help verify, please
  email me.

There will be a PSTN bridge for a backup, should things completely fail.
We will have a dial-in phone number connected to the bridge for those that
are unable to connect with a computer, but it won't be toll-free.
The phone numbers involved will be posted to the agenda as it is finalized,
and we expect to distribute slides by January 27, 2015.

(BTW: we do not believe that ROLL will meet in Dallas/IETF92)

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

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 13 Feb 2015 15:47:23 +0100

Hi Pascal,

I fully support your email. I think it is very important we address this
issues now. Most of us followed rfc6282 and rfc6550-4 family in our
implementations and never understood from there the requirement for IP in
IP. Later we discovered the dispatch-03 draft which indicates clearly the
need but most of the code I've seen does not support that at all.

>From an implementer point of view, I see really inefficient this
encapsulation and in fact it is jeopardizing the little space we have in
the packets when eventually headers need to be "touched" at the lbr anyway.
This is specially "significant" in source routing in non-storing mode and
when the inner header cannot be compressed.

It would be very valuable to see what Zigbee IP people have done to cope
with that. Could we find that information? Could someone present the zigbee
IP solution at the next group meeting?

>From your 4 points):

a)      Document our own layouts in storing and non-storing, bypassing 6MAN
for this round, no IPinIP

b)      Follow the ZigbeeIP specs, whatever was done and tested there, and
try to standardize it at ROLL

c)      Wait for ROLL and implement their flows - compressing only the
encapsulating IP header in case of IPinIP

d)      Implement what we have on the table, either FL, NHC, 6LoRH or a
combination thereof, to get implementation feedback

e)

I see an option to go for c) maybe with that we can show how inefficient it
is and trigger some reactions. Then d) 6LoRH and NHC seem to me the best
candidates for compression but they are not WG documents so not sure how
far they will go. b) might be a good option but I do not know how long it
would take to implementors to know about it and implement it in their
frameworks.

Note that what we are pointing out here is showing a clear drift between
what it is actually implemented and what WG are standadizing.

What others think?

regards,
Xavi

2015-02-11 16:12 GMT+01:00 Pascal Thubert (pthubert) <[email-masked]>:
Dear all:

The first plugtest is being defined now. Unless we wait to uncover the
issues and suffer at the test, we need to agree on what the frames will be.

The interim discussion pointed out that IPv6 –and the specs that went
through 6MAN- expects the addition on IPinIP when headers have to be
stripped or added by an intermediate router.
ROLL should produce rapidly a spec that disambiguates the frame content in
various steps of storing and non-storing.

It must be noted that there is no possible RFC 6282 compression after a RH3
or a RPI HbH with the existing specs since these are not compressed. So
IPinIP to add/remove RH3 or RPI basically prevents 6lowpan compression of
the inner packet. Robert pointed out that ZibgeeIP has addressed this issue
and we expect

Nevertheless, my understanding is that most implementation never do IPinIP,
but rather reshuffle the headers. It will probably take time till ROLL
comes back with the exact frame layouts as IPv6 would expect them. It is
still unclear what the compression will be since the reuse of the ‘10’
mesh-under dispatch raises political concerns.

So what do we do for the plugtest? Out of my hat I see the following
possibilities:

a)      Document our own layouts in storing and non-storing, bypassing 6MAN
for this round, no IPinIP

b)      Follow the ZigbeeIP specs, whatever was done and tested there, and
try to standardize it at ROLL

c)      Wait for ROLL and implement their flows - compressing only the
encapsulating IP header in case of IPinIP

d)      Implement what we have on the table, either FL, NHC, 6LoRH or a
combination thereof, to get implementation feedback

e)       ?

Questions arise :

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Ines Robles
Sent: mercredi 11 février 2015 02:42
To: roll
Cc: Adrian Farrel; [email-masked]; [email-masked]; Brian Haberman;
[email-masked] WG
Subject: Re: [6tisch] [Roll] virtual interim meeting for ROLL: 2015-02-10,
15:00 UTC

Hello,

Please find a draft of the minutes here:
http://www.ietf.org/proceedings/interim/2015/02/10/roll/minutes/minutes-interim-2015-roll-1

Cheers,

Michael and Ines.

Please find an updated slides at
http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-3.pdf

Thanks,

Please find a draft of the slides here
http://www.ietf.org/proceedings/interim/2015/02/10/roll/slides/slides-interim-2015-roll-1-1.pdf

Thank you very much,

Michael and Ines.

In accordance with:
https://www.ietf.org/iesg/statement/interim-meetings.html
the ROLL Working Group Chairs are announcing a virtual interim meeting for
February 10, 2015, from 15:00 UTC to 18:00 UTC.
      (please see: http://goo.gl/NVefsy to convert the time)

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

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