Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

["Pascal Thubert (pthubert)" <[e-mail]>]

Cool

Let us update the agenda to make more room then.

Could you please prepare a slide or 2 illustrating what the problem is?

Also I'd like to provide examples at the call. If you have some that illustrate your issues please send them on the lists so I can provide the 6lorh form to compare.

Thanks a bunch Simon!

Pascal

> Le 20 janv. 2016 à 09:08, Simon Duquennoy <[e-mail]> a écrit :
> 
> Yes let me participate to the next 6TiSCH interim. I'll be also at the plugtest.
> Will be much easier over voice ;)
> Thanks,
> Simon
> 
> 
> On Wed, Jan 20, 2016 at 8:54 AM, Pascal Thubert (pthubert)
> <[e-mail]> wrote:
>> Our messages crossed, Simon.
>> 
>>> - IPv6 stack interacting with the adaptation layer
>> 
>> I'm not sure I agree with that (see my other mail), but if you're correct I really what to dig that and fix it.  Please read the other email I just sent and if you still see that the mapping is not there then please refine what the issue is exactly.
>> 
>> 
>>> - No one-to-one mapping between a RH3-6LoRH and a RH3
>> 
>> We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and recompress an RH0 into both as well. I fail to see what the problem is though I do hope that implementations never need to play that game. When the packet goes up the stack, the RH3-6LoRH should be gone, removed by the last router (which may be collocated).
>> 
>> Would you be willing to participate to the next 6TiSCH interim? We'll discuss that topic since it impacts the plugtest.
>> 
>> Cheers,
>> 
>> Pascal
>> 
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> On Behalf Of Simon Duquennoy
>>> Sent: mercredi 20 janvier 2016 08:44
>>> To: Michael Richardson <[e-mail]>
>>> Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail];
>>> Routing Over Low power and Lossy networks <[e-mail]>; Tengfei Chang
>>> <[e-mail]>; [e-mail]
>>> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
>>> 
>>> Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry for the
>>> confusion.
>>> 
>>> What I don't like:
>>> - IPv6 stack interacting with the adaptation layer
>>> - No one-to-one mapping between a RH3-6LoRH and a RH3
>>> 
>>> If I'm not mistaken, everything else in 6lowpan offers this one-to-one
>>> mapping, and that allows the IPv6 stack to work independently of 6lowpan
>>> (i.e. the same stack runs both in 6lowpan environment or not).
>>> I also find this property nice, conceptually, as one can produce any
>>> IPv6 packet and easily derive its compressed form, and back. One header
>>> maps to one compressed header with all its fields compressed, etc.
>>> 
>>> If I'm the only one to think this is an issue, I'm ready to close the issue.
>>> 
>>> Thanks,
>>> Simon
>>> 
>>> 
>>> On Tue, Jan 19, 2016 at 11:06 PM, Michael Richardson
>>> <[e-mail]> wrote:
>>>> 
>>>> Simon Duquennoy <[e-mail]> wrote:
>>>>> Not really. It was rather my view of the architecture that differs a
>>>>> bit from what you describe in your previous mail.
>>>> 
>>>> okay.
>>>> 
>>>>> For me RPL produces the RH3 and then passes the packet down the
>>> stack
>>>>> for compression. Or for incoming packets, first there is
>>>>> decompression, then the IPv6 packet with its headers and extension
>>>>> headers are passed up to RPL etc. If find it odd to force upper layers
>>>>> to work on 6lowpan compressed formats.
>>>> 
>>>> RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND
>>> messages.
>>>> 
>>>> I think the thing you are describing is the IPv6 stack, and you don't
>>>> like that the IPv6 stack has to interact with the link adaptation layer.
>>>> 
>>>> --
>>>> Michael Richardson <[e-mail]>, Sandelman Software
>>> Works
>>>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>>>>