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
