Will do, talk to you on Friday! Thanks, Simon Le 20 janv. 2016 09:14, "Pascal Thubert (pthubert)" <[email protected]> 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 <[email protected]> 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) > > <[email protected]> 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: [email protected] [mailto:[email protected]] > >>> On Behalf Of Simon Duquennoy > >>> Sent: mercredi 20 janvier 2016 08:44 > >>> To: Michael Richardson <[email protected]> > >>> Cc: Pascal Thubert (pthubert) <[email protected]>; [email protected]; > >>> Routing Over Low power and Lossy networks <[email protected]>; Tengfei > Chang > >>> <[email protected]>; [email protected] > >>> 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 > >>> <[email protected]> wrote: > >>>> > >>>> Simon Duquennoy <[email protected]> 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 <[email protected]>, Sandelman Software > >>> Works > >>>> IETF ROLL WG co-chair. > http://datatracker.ietf.org/wg/roll/charter/ > >>>> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
