Sounds good, thanks in advance for the update, request noted. > -----Original Message----- > From: Carles Gomez Montenegro <[email protected]> > Sent: 20 June, 2018 22:11 > To: Gabriel Montenegro <[email protected]> > Cc: Samita Chakrabarti <[email protected]>; > [email protected]; lo <[email protected]>; [email protected] > Subject: Re: [6lo] Status of draft-ietf-6lo-blemesh-02 > > Hi Gabriel, > > Thanks for the follow-up. > > Yes, we would like to request some time for Montreal. Our aim would be > explaining the following: > > - The updates in -03 (which we plan to publish before the cut-off date), > including text on network formation/initialization. > > - Related with the updates, we have teamed up with Michael Spörk and his > colleagues, from Graz University of Technology, who are the authors of the > BLEach implementation of RFC 7668 [1]. We are already running our own local > copy (at UPC) of a BLEach scenario, which we plan to use as the basis to > implement draft-ietf-6lo-blemesh. > > - Since in the past there have been questions on the Bluetooth SIG proposal > for > BLE mesh networking, it might be good to show one slide on the topic, now > that the "Bluetooth mesh" specification (from Bluetooth > SIG) is publicly available, explaining the differences with RFC 7668 and > draft- > ietf-6lo-blemesh. > > I guess a 10-min slot should work, but a shorter slot would be fine if needed > to > accommodate other slot requests. > > Please let us know if you have any comments. > > Thanks! > > Carles > > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.re > searchgate.net%2Fprofile%2FMarco_Zimmerling%2Fpublication%2F319315009 > _BLEach_Exploiting_the_Full_Potential_of_IPv6_over_BLE_in_Constrained_Em > bedded_IoT_Devices%2Flinks%2F59dc8148458515e9ab4c6737%2FBLEach- > Exploiting-the-Full-Potential-of-IPv6-over-BLE-in-Constrained-Embedded-IoT- > Devices.pdf&data=02%7C01%7CGabriel.Montenegro%40microsoft.com%7Ce4 > ce522390ae465ade0908d5d7356d01%7C72f988bf86f141af91ab2d7cd011db47 > %7C1%7C0%7C636651546827616958&sdata=YxUT2yuOeq3z03lUxy8sdyJ45Wa > dobI0El88ENV2iwY%3D&reserved=0 > > > > > HI Carles, > > > > Below, you indicate you might have some updates for Montreal. > > > > Would you like some time during the meeting to discuss any progress > > you may have had on the implementation and validation of the spec? Not > > ready yet? > > > > Thanks, > > > > Gabriel > > > > From: 6lo <[email protected]> On Behalf Of Samita Chakrabarti > > Sent: 16 March, 2018 05:16 > > To: Carles Gomez Montenegro <[email protected]> > > Cc: [email protected]; lo <[email protected]> > > Subject: Re: [6lo] Status of draft-ietf-6lo-blemesh-02 > > > > Thank you Carles for the implementation update of BLEmesh.. > > Great work in finding out and sharing the ble existing base > > implementations pros and cons. That is helpful for 6lo wg and it is > > good to know that Contiki now supports RFC 7668. > > -Samita > > > > > > > > > > > > On Mar 16, 2018 4:38 AM, "Carles Gomez Montenegro" > > <[email protected]<mailto:[email protected]>> wrote: > > Dear WG, > > > > We would like to provide a short report on the status and our > > activities related with draft-ietf-6lo-blemesh-02. > > > > As you may recall, while we believe the document to be ready, we > > wanted to implement it before proceeding further. > > > > We had planned to implement the draft based on Raspberry Pi devices > > and BlueZ. We actually enabled an RFC 7668 scenario with one device as > > a master (or a 6LBR), another one as a slave (or a 6LN), and even > > IPv6-based communication between the 6LN and a non-BLE interface of > > the 6LBR was working well. > > > > However, when we tried to increase the number of 6LNs per 6LBR, we > > encountered the issue that communication between the 6LBR and the > > already existing 6LN stopped working. > > > > It appears that several concurrent BLE connections are not handled > > correctly with BlueZ. This is a problem other people have found, and > > as per the BlueZ mailing list, there is not a currently known solution. > > > > Fortunately, we have found another basis for our implementation. > > Recently, > > the BLEach open implementation of RFC 7668 (based on Contiki and > > CC2650 > > devices) was released > > > (https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fspoerk..g > ithub.io%2Fcontiki&data=02%7C01%7CGabriel.Montenegro%40microsoft.com > %7Ce4ce522390ae465ade0908d5d7356d01%7C72f988bf86f141af91ab2d7cd01 > 1db47%7C1%7C0%7C636651546827616958&sdata=3uZWh4AKuw11mGU2DG > 4qAoBeYmxWYU24NT6wRsm3VKg%3D&reserved=0<https://na01.safelinks.pr > otection.outlook.com/?url=http%3A%2F%2Fspoerk.github.io%2Fcontiki&data > =04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d2296594d8b > 0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > 6567993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C- > 1&sdata=gg8G01srzJ3e6X1IbLwUQ2mFcqhPq9Wm9FUTBry8XFw%3D&reserve > d=0>). > > It is promising, > > as in fact results are shown by BLEeach authors on a scenario with one > > 6LBR and several 6LNs. We are currently in the process of enabling the > > RFC > > 7668 > > scenario based on this platform, and then we plan to modify/extend the > > code in order to implement our draft. > > > > Our plan is to have a first prototype implementation by IETF 102 > > (Montreal), and request to give a report in the 6Lo session of that > > meeting. > > > > Meanwhile, please let us know whether you have any comments on the draft. > > And, of course, any feedback from implementation experience will be > > very much appreciated! > > > > (Note: when the I-D submission tool reopens, we will upload a new > > version of the draft as "a refresher".) > > > > Thanks! > > > > Carles, Mahdi, Teemu > > > > _______________________________________________ > > 6lo mailing list > > [email protected]<mailto:[email protected]> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i > > > etf.org%2Fmailman%2Flistinfo%2F6lo&data=02%7C01%7CGabriel.Montenegro > %4 > > > 0microsoft.com%7Ce4ce522390ae465ade0908d5d7356d01%7C72f988bf86f14 > 1af91 > > > ab2d7cd011db47%7C1%7C0%7C636651546827616958&sdata=HUE%2FXg8FZc > buPFtVs1 > > > feFmsse8Cc77jPT2azP2Q5W4o%3D&reserved=0<https://na01.safelinks.protec > t > > > ion.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo% > 2 > > > F6lo&data=04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d22 > 96594 > > > d8b0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 > C63656 > > > 7993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > QIjoiV2lu > > MzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C- > 1&sdata=fVu7RwdS7gDMMvY5N0iLrwe201uqtt > > E58Gw3eHrKqhE%3D&reserved=0> > > > > _______________________________________________ > > 6lo mailing list > > [email protected] > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i > > > etf.org%2Fmailman%2Flistinfo%2F6lo&data=02%7C01%7CGabriel.Montenegro > %4 > > > 0microsoft.com%7Ce4ce522390ae465ade0908d5d7356d01%7C72f988bf86f14 > 1af91 > > > ab2d7cd011db47%7C1%7C0%7C636651546827616958&sdata=HUE%2FXg8FZc > buPFtVs1 > > feFmsse8Cc77jPT2azP2Q5W4o%3D&reserved=0 > > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
