Re: [6tisch] Optimizing Neighbor Discovery during the join process

2018-04-20 Thread Michael Richardson
mcr> 1) What L2 address would the JP use in the Enhanced Beacon? mcr> Could we mandate that whatever it uses there, that it also configure as mcr> a valid l3 LL address? It doesn't have to use that address by default mcr> for any other traffic. mcr> mcr> 2) we could

Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)

2018-04-20 Thread 王沁
Hi Alexey, Please see inline. Thanks Qin -原始邮件- 发件人:"Alexey Melnikov" 发送时间:2018-04-20 18:48:55 (星期五) 收件人: "Qin Wang" , "Xavi Vilajosana Guillen" 抄送: tisch <6tisch@ietf.org>, "Pascal Thubert" ,

Re: [6tisch] Optimizing Neighbor Discovery during the join process

2018-04-20 Thread Pascal Thubert (pthubert)
Hello Mališa All the below makes sense to me and I agree with the general direction that you are taking. Let’s see the final text – and don’t forget to signal in the join that the LL derives from the MAC so on the way back we skip the look up! Take care, Pascal From: Mališa Vučinić

Re: [6tisch] Optimizing Neighbor Discovery during the join process

2018-04-20 Thread Mališa Vučinić
Hi Pascal, Thanks for the clarifications. One point I strongly disagree with is about the cost of the ND exchange. ND is indeed done on one-hop but in 6TiSCH case this maps to the* shared cell*, where the collisions happen. Once we get pass that critical first hop, things are much easier as we

Re: [6tisch] review of draft-vilajosana-6tisch-globaltime-00

2018-04-20 Thread Xavi Vilajosana Guillen
Dear Georgios, thanks so much for your detailed review. Let me answer inline. The fixes will appear in a next version of the draft. kind regards Xavi 2018-04-09 11:26 GMT+02:00 Georgios Z. Papadopoulos < georgios.papadopou...@imt-atlantique.fr>: > Hello Xavi and co-authors, > > Many thanks

Re: [6tisch] Optimizing Neighbor Discovery during the join process

2018-04-20 Thread Pascal Thubert (pthubert)
Hello Micheal: > > 1) What L2 address would the JP use in the Enhanced Beacon? >Could we mandate that whatever it uses there, that it also configure as >a valid l3 LL address? It doesn't have to use that address by default >for any other traffic. > > 2) we could include the

Re: [6tisch] Alexey Melnikov's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)

2018-04-20 Thread Alexey Melnikov
Hi Qin, On Thu, Apr 19, 2018, at 9:51 PM, Qin Wang wrote: > > Hi Alexey, > > Thank you for your further comments. Please see inline. > > Qin > > On Thursday, April 12, 2018, 1:20:01 PM EDT, Alexey Melnikov > wrote:> > > Hi Xavi, > > On Fri, Apr 6, 2018, at 4:39 PM,

Re: [6tisch] Optimizing Neighbor Discovery during the join process

2018-04-20 Thread Pascal Thubert (pthubert)
Hello Mališa The all-0 destination is tricky, not done anymore that I know off. Trying that may get us through hell at 6MAN and/or IESG. I think that as an RFC you must described the clean way and then the optimizations when the LLs are based on EUI 64. IMHO, the spec should say that: -