Subject: [Int-dir] Review of draft-ietf-6lo-btle

From: Jouni Korhonen <[email-masked]>
Date: Wed, 15 Apr 2015 17:16:08 -0700

Hi,

I was asked to do the Internet Directorate review of draft-ietf-6lo-btle-10.

Technically I think the document is ready except for few nits. The 
comments are below:

* Section 1

    which means that low power consumption is essential.  Bluetooth LE is
    an especially attractive technology for Internet of Things
    ^^

Would remove 'an' here'

* Section 1

    Considering the potential for the exponential growth in the number of
    sensors and Internet connected devices and things, IPv6 is an ideal
                                               ^^^^^^^
Although I know what you are after with the "things" it somehow does not 
seem to fit here. I recommend removing the word.

* Section 2.3

    These random device addresses have a very small chance of being in
    conflict, as Bluetooth LE does not support random device address
    collision avoidance or detection.

I do not parse this sentence. Is it trying to say that there is no 
Bluetooth specific mechanims to avoid or detect duplicate Bluetooth 
devices addresses because the assumption is that such collision is very 
rare?

* Section 3

    Bluetooth SIG in the IPSP specification [IPSP].  In the rare case of
    Bluetooth LE random device address conflict, the 6LBR can detect
    multiple 6LNs with the same Bluetooth LE device address.  The 6LBR
    MUST have at most one connection for a given Bluetooth LE device

What happens if 6LN and 6LBR happen to have colliding device addresses? 
How is that handled?

* Section 3.2.1

OLD:
    DHCPv6 [RFC3315].  The non-link-local addresses 6LN generates must be
    registered with 6LBR as described in Section 3.2.2.
NEW:
    DHCPv6 [RFC3315].  The non-link-local addresses 6LN generates MUST be
    registered with 6LBR as described in Section 3.2.2.

* Section 3.2.2

    1.  A Bluetooth LE 6LN SHOULD NOT register its link-local address.  A
    Bluetooth LE 6LN MUST register its non-link-local addresses with the

What is the case when a BT LE 6LN can go against the SHOULD NOT and 
register its link-local address?

* Section 3.3

Is it possible for a 6LBR to be connected to another 6LBR instead of a 
6LN (referring to Figure 7)?

- JOuni

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Apr 2015 02:04:42 +0000

Thanks much Jouni!

- Bernie (from iPad)

> On Apr 15, 2015, at 8:16 PM, Jouni Korhonen <[email-masked]> wrote:
> 
> Hi,
> 
> Technically I think the document is ready except for few nits. The comments are below:
> 
> * Section 1
> 
> Although I know what you are after with the "things" it somehow does not seem to fit here. I recommend removing the word.
> 
> * Section 2.3
> 
> I do not parse this sentence. Is it trying to say that there is no Bluetooth specific mechanims to avoid or detect duplicate Bluetooth devices addresses because the assumption is that such collision is very rare?
> 
> * Section 3
> 
> What happens if 6LN and 6LBR happen to have colliding device addresses? How is that handled?
> 
> * Section 3.2.1
> 
> OLD:
> What is the case when a BT LE 6LN can go against the SHOULD NOT and register its link-local address?
> 
> * Section 3.3
> 
> Is it possible for a 6LBR to be connected to another 6LBR instead of a 6LN (referring to Figure 7)?
> 
> - JOuni

---

From: Brian Haberman <[email-masked]>
Date: Fri, 17 Apr 2015 09:41:28 -0400

Jouni,
     Thanks for the review.  Very helpful.

Regards,
Brian

On 4/15/15 8:16 PM, Jouni Korhonen wrote:
> _______________________________________________
> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir
> 
>

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Tue, 21 Apr 2015 11:41:02 +0000

Hi Jouni,

And thanks for review. Please see replies inline.

>    an especially attractive technology for Internet of Things

Removed.

>                                              ^^^^^^^ Although I know what you are after with the "things" it somehow does not seem to fit here. I recommend removing the word.

Right, sounds better after removing the word.

>I do not parse this sentence. Is it trying to say that there is no Bluetooth specific mechanims to avoid or detect duplicate Bluetooth devices addresses because the assumption is that such collision…

Yes. Reworded a bit:
--
These random device addresses have a very small chance of being in conflict, as there are no Bluetooth LE specific mechanisms for supporting random device address collision detection or avoidance.
--

>What happens if 6LN and 6LBR happen to have colliding device addresses? 

Well, when 6LBR is scanning for devices and if it finds 6LN with same device address than itself, it just would have to ignore that 6LN (until the 6LN changes its address to one not in conflict, which it will when using random addresses). How about rewording the above to:
--
In the rare case of Bluetooth LE random device address conflict, a 6LBR can detect multiple 6LNs with the same Bluetooth LE device address or 6LNs with the same address the 6LBR is using. The 6LBR MUST ignore 6LNs with the same device address the 6LBR has, and the 6LBR MUST have at most one connection for a given Bluetooth LE device address at any given moment.
--

>    registered with 6LBR as described in Section 3.2.2.

Fixed.

>What is the case when a BT LE 6LN can go against the SHOULD NOT and register its link-local address?

Registering link-local address would be waste of resources, but host may waste resources if it likes:) 

Seriously, good point. I think we can change this to MUST NOT as we nowadays say earlier that link-local addresses are always bound to device address a device has. Hence registering it probably would have no benefit but could be source of errors.

New text:" 1.  A Bluetooth LE 6LN MUST NOT register its link-local address.".

>Is it possible for a 6LBR to be connected to another 6LBR instead of a 6LN (referring to Figure 7)?

BLE mesh is out-of-scope of this document, so no..

Best regards,

	Teemu

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Tue, 21 Apr 2015 13:07:04 -0700

> Thanks much Jouni!

+1

>> Although I know what you are after with the "things" it somehow does 
>> not seem to fit here. I recommend removing the word.
>>
>> * Section 2.3
>>
>> devices addresses because the assumption is that such collision is 
>> very rare?
>>
>> * Section 3
>>

--
李柯睿
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 21 Apr 2015 14:14:32 -0700

Hi Teemu,

See my responses inline.

>> I do not parse this sentence. Is it trying to say that there is no Bluetooth specific mechanims to avoid or detect duplicate Bluetooth devices addresses because the assumption is that such collisi…

I still find the wording confusing. Let me try:

      Bluetooth LE does not support device address collision avoidance
      or detection. However, these 48 bit random device addresses have a
      very small propability of being in conflict within a typical
      deployment.

> In the rare case of Bluetooth LE random device address conflict, a 6LBR
 > can detect multiple 6LNs with the same Bluetooth LE device address or 
6LNs
 > with the same address the 6LBR is using. The 6LBR MUST ignore 6LNs with
 > the same device address the 6LBR has, and the 6LBR MUST have at most one
 > connection for a given Bluetooth LE device address at any given moment.
> --

WFM.

> New text:" 1.  A Bluetooth LE 6LN MUST NOT register its link-local address.".

WFM.

> BLE mesh is out-of-scope of this document, so no..

Ack.

- Jouni

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Fri, 24 Apr 2015 10:28:43 +0000

>      very small propability of being in conflict within a typical

I used that with addition of detail indicating that this randomization typically happens when power cycle occurs:

The random device addresses are generated as defined in the Bluetooth specification. This typically
happens at every power cycle of a device. In random addresses all 48 bits are randomized. 
Bluetooth LE does not support device address collision avoidance or detection. However, 
these 48 bit random device addresses have a very small probability of being in conflict within a typical
deployment.

>> can detect multiple 6LNs with the same Bluetooth LE device address or 6LNs  with the same address the 6LBR is using. The 6LBR MUST ignore 6LNs with  > the same device address the 6LBR has, and the 6LBR MUST have at most one  > connection for a given Bluetooth LE device address at any given moment.
>> --
>WFM.

Tuned a bit more:

In the rare case of Bluetooth LE random device
address conflict, a 6LBR can detect multiple 6LNs with the same Bluetooth LE device address, as well as a 6LN
with the same Bluetooth LE address as the 6LBR. The 6LBR MUST ignore 6LNs with the same device address the 6LBR has, and the 6LBR MUST 
have at most one connection for a given Bluetooth LE device address at
any given moment.

Best regards,

	Teemu

---

From: Jouni <[email-masked]>
Date: Fri, 24 Apr 2015 07:42:13 -0700

> On 24 Apr 2015, at 03:28, Savolainen Teemu (Nokia-TECH/Tampere) <[email-masked]> wrote:
> 

Better and works for me.. The power cycle thing pretty much voids all cleans ways to react to address collisions.

> have at most one connection for a given Bluetooth LE device address at

This is ok.

Thanks,
	Jouni