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

["Savolainen Teemu (Nokia-TECH/Tampere)" <[e-mail]>]

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.

>>   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?

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