Hi Juan Carlos:
Thanks for providing the link.
I had a brief look at the presentation by Pat Thaler (first weblink below):
1) Slide 5:
Somehow, I still do not understand the need for partitioning of the address space, where part is for "local administration". This seems to be the crux of the 24/24 address partitioning debate triggered by the 802.c PAR, so important to understand better. What
is the concern/use case that I am missing?
[pat] In some environments such as a data center, some addresses may be configured by an administrator. This was the initial use envisioned for local MAC addresses. Many 802.5 nodes
used configured local addresses). Some DEC devices Such nodes generally don’t “know” that their address is configured. They are just using what was set in their address register. They won’t be participating in any address acquisition protocol so they won’t
participate in a duplicate address check and they have no ability to change addresses if there is a duplicate.
This kind of use has been allowed since the beginning of IEEE 802 and we need to allow for it to continue. It would be nice for administrators going forward to be able to know what
address range to use without conflicting with other newer ways to get addresses.
Also, some data centers can have a large number of entities on the network. Virtualization and cloud increases this number quite a lot. An address acquisition protocol such as distribution
of address by a hypervisor orchestration system might have a default block in the CID space, but for cases where 2^24 addresses aren’t enough additional space might be assigned from the local administration block by the administrator to the orchestration system.
[pat]
2) Slide 12:
Pseudo-random address generation with 24 bits of freedom easily leads to clashes well before ~1000 devices (due to the so-called birthday paradox);
[pat] In an address claiming protocol (i.e. a protocol where a device randomly generates part of the address and then checks for duplicates before using), the birthday paradox doesn’t
matter. When a device needs an address, it sends a claim frame to see if the address is in use. If the address is in use, it will get a response to its claim, choose another address and repeat the process. So yes, the birthday paradox says that one or even
a few may need to try more than once.
For 1000 devices and 24 bits, there is about a probability of 3% that at least one of the devices fails to get a unique address on the first try. The important thing is that At that
point one has ~999 devices that have successfully chosen an address.
The device that failed (or perhaps in a very unlucky case 2 or 3 devices) will repeat the process of generating a new address. It has a probability of less than 0.006% that the second
attempt fails.
If making 2 or 3 attempts is unacceptable in a particular application or if you want unique addresses for a stadium full of people, then use an server-based protocol instead of a claiming
protocol. [pat]
Partitioning of address space accross multiple servers, with pre-assigned ranges, seems wasteful, since in practice the requirements per server may not be the same.
[pat] The 2^24 blocks are intended to be per protocol. The protocol would use that as its default block in all its deployments. There might be multiple servers on a given network.
For instance, in the FCoE server-based case, each Fibre Channel Forwarder (the FC switch protocol running as layer 3 over 802.1Q bridges) is a server and the block is divided amongst the servers.
There are 16 million addresses available in a CID block for a server based protocol so that should provide plenty for dividing amongst the servers. But if there is a concern about
having enough addresses, a protocol doesn’t have to allocate a fixed range to each server. A protocol could run between servers with each server requesting the quantity of addresses it initially needs. [pat]
Overall, it is hard to see what the downside would be to having pseudo-random addresses of 48 (well: 46 bits) in the sketched scenario, except perhaps for network segregation. If address generation is local (ethernet in cars, etc.) and messaging would use authentication,
one does not need to worry about this segregation issue. Moreover, (as Dan Harkins already pointed out before), the probability of clashes is quite low with 46 bits of freedom for pseudo-random address generation. One can implement DAD or use server-allocation
addresses (Slide 15) to mitigate potential clashes, should these still occur.
[pat] The downside is that occasional clashes will occur. A pseudo-random address scheme using the whole local address space assumes that all devices and all servers participate in
duplicate address detection to identify and resolve the duplicate addresses. Duplicate address detection also assumes that all devices can see all other devices or at least see something that will proxy for addresses on the network that it can’t see. If that
isn’t the case, duplicate addresses can go undetected.
There isn’t a universal duplicate address detection protocol. As I’ve mentioned above and before, devices using administrator configured local addresses (devices that already exist)
won’t be participating in a duplicate address detection protocol. Nor will the existing VMs with local addresses assigned by a virtualization orchestration system.
Partitioning allows each protocol to use a duplicate address detection that is appropriate for the protocol while not conflicting with other protocols. [pat]
3) Slide 17:
Not sure whether one does not need a unique id for IoT devices. In many settings, one may want this, e.g., for white listing and configuration purposes. This does not have to be a burned in address at manufacturing, since recoverability hereof by the device,
e.g., at start-up, does suffice. So, even if one has a unique id, this does not necessarily result in increased manufacturing cost.
[pat] I expect that some but not all devices using local addresses will need a unique ID – in some cases an EUI-64. In any case, that was a minor point. [pat]
Best regards, Rene
On 10/22/2014 3:02 PM, Zuniga, Juan Carlos wrote: