Subject: [6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-btle-14: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 08 Jul 2015 20:42:58 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-6lo-btle-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In this text:

   New addresses are typically generated each time a
   device is powered on.  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.
   
is the working assumption that if a random device address conflict does
arise, either a human will recycle power because that's what humans do
with electronic devices that don't work, or if no impatient human is
available, the device will power off and back on eventually and
everything will be fine?

I'm looking at this text:

   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.  This will avoid
   addressing conflicts within a Bluetooth LE network.
   
and guessing that the Bluetooth LE network doesn't have addressing
conflicts, but does that mean that the device that's trying to use a
random device address that would cause addressing conflicts if it wasn't
being ignored will give up and choose another random device address?

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Thu, 9 Jul 2015 05:58:29 +0000

Thank you Spencer for your review.

>is the working assumption that if a random device address conflict does arise, either a human will recycle power because that's what humans do with electronic devices that don't work, or if no impatient human is available, the device will power off and back on eventually and everything will be fine?

Well, if a device is implemented so that it randomizes its device address only at boot, it will actually have to be kicked to perform randomization operation again.

The Bluetooth LE specification just does not have automatic address conflict resolution solution. 

My understanding is that when that decision was made, the likelihood of address conflict was considered to be too low to warrant complexity of conflict resolution logic. That view still stands, afaik. I cannot but see here a conflict between practicality and perfection, which we must find balance on:)

In overall, I see the small LE device address conflict possibility as a property and problem of Bluetooth LE, and I wish to minimize specification work we done to address that. If it becomes a real issue in LE market, BT SIG should fix it.

>and guessing that the Bluetooth LE network doesn't have addressing conflicts, but does that mean that the device that's trying to use a random device address that would cause addressing conflicts if it wasn't being ignored will give up and choose another random device address?

That was written to avoid 6LBR connecting multiple times to the same node and to avoid address conflict issues in header compression (to avoid situation with multiple 6LNs with same link-local address). The device that selects conflicting random address will be left stranded. It does not necessarily realize it does not get service due conflict, and hence human intervention is required to perform power cycle. This is the way BT SIG wanted it, and if this becomes a problem in real life, it is BT SIG that needs find solution for it.

Best regards,

Teemu