Subject: Re: [6lo] Status of draft-ietf-6lo-blemesh-02

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 20 Jun 2018 21:23:35 +0000

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-masked]> On Behalf Of Samita Chakrabarti
Sent: 16 March, 2018 05:16
To: Carles Gomez Montenegro <[email-masked]>
Cc: [email-masked]; lo <[email-masked]>
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-masked]<mailto:[email-masked]>> 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 (http://spoerk.github.io/contiki<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fspoerk.github.io%2Fcontiki&data=04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d2296594d8b0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=gg8G01srzJ3e6X1IbLwUQ2mFcqhPq9Wm9FUTBry8XFw%3D&reserved=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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d2296594d8b0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=fVu7RwdS7gDMMvY5N0iLrwe201uqttE58Gw3eHrKqhE%3D&reserved=0>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 21 Jun 2018 07:11:11 +0200

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://www.researchgate.net/profile/Marco_Zimmerling/publication/319315009_BLEach_Exploiting_the_Full_Potential_of_IPv6_over_BLE_in_Constrained_Embedded_IoT_Devices/links/59dc8148458515e9ab4c6737/BLEach-Exploiting-the-Full-Potential-of-IPv6-over-BLE-in-Constrained-Embedded-IoT-Devices.pdf

> 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
>
> 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-masked]<mailto:[email-masked]>> wrote:
> Dear WG,
>
> devices) was released
> (http://spoerk.github.io/contiki<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fspoerk.github.io%2Fcontiki&data=04%7C01%7CGabriel.Montenegro%40microsoft.com%7Cb1ab5d2296594d8b0f2108d58b37a9d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636567993550354044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=gg8G01srzJ3e6X1IbLwUQ2mFcqhPq9Wm9FUTBry8XFw%3D&reserved=0>).
> It is promising,
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 21 Jun 2018 16:19:20 +0000

Sounds good, thanks in advance for the update, request noted.

> -----Original Message-----
> From: Carles Gomez Montenegro <[email-masked]>
> Sent: 20 June, 2018 22:11
> To: Gabriel Montenegro <[email-masked]>
> Cc: Samita Chakrabarti <[email-masked]>;
> [email-masked]; lo <[email-masked]>; [email-masked]
> 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.
> 
> 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,
> >
> > 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
> >
> > implementations pros and cons. That is helpful for 6lo wg and it is
> > good to know that Contiki now supports RFC 7668.
> >  -Samita
> >
> >
> >
> >
> >
> > 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.
> >
> > encountered the issue that communication between the 6LBR and the
> > already existing 6LN stopped working.
> >
> > 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.
> >
> (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,
> > 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
> >
> > 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>
> >
> > 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
> >
>