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

[Simon Duquennoy <[e-mail]>]

Will do, talk to you on Friday!
Thanks,
Simon
Le 20 janv. 2016 09:14, "Pascal Thubert (pthubert)" <[e-mail]> a
écrit :

> 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/
> >>>>
>