Bob,
Thanks for your reply and views. Thanks also to Pat for additional
perspectives. The discussion has been very helpful. I still have
questions and concerns, though. Here are a few issues on my mind:
(1) You've suggested that there are "Lots of possibilities here. How
about 44 bits? One quadrant of the local space for the 'wild west', one
for CID based automated assignment, one for …" Pat has also been talking
about quadrants. Has the RAC has already decided to divide the local
space
four ways? I don't see that position documented anywhere. However, when
I look at the CID Public
Listing, I see that the
RA has kept just 4 of the 24 bits consistent across the assignments.
Those 4 bits are the 4 LSBs of the first byte; in each case, 1010. The
last of these are the 802 local and multicast bits. In fact, after only
the first 6 public CIDs were assigned, not a single bit (other than the 4
LSBs of the first byte) had been assigned consistently. So, based on
this review, it appears to me as if the RA is assigning all CIDs with
"10" in the bits adjacent to the 802-specific bits and ensuring that no
other bit of the CID is used consistently. Can I take that as a
sign that the RAC policy is to stake out a full quadrant of the local
space
for CIDs?
Pat also mentioned existing Fibre Channel over Ethernet applications in
the local space. It seems that the FCoE standard is limited to a small
slice of the "11" quadrant. It looks as if the RAC may have decided to
avoid conflict with FCoE when it settled on "10". So it looks like the
RAC intends to use "00" or "01" for the "wild west".
(2) I
have no
qualms about the RAC creating the CID and assigning values. However, I
still see contradictions in building a MAC address from such a CID. Per
IEEE Std 802,
"If the U/L bit is set to 1, the remaining bits (i.e., all bits except
the I/G and U/L bits) are locally administered and should not be
expected to meet the uniqueness requirement of the IEEE RA-assigned
values." [Of course, a future
802c amendment could alter this situation.]
(3) Perhaps my request
for a "clear indication of the
expected usage model" was
overstated. Still, I think that the CSD require more explanation
of the intention and potential effects. Under 1.2.2, variances in
conformance with IEEE Std 802
need to be "thoroughly disclosed and reviewed." Also, since the number
space
is finite, we ought to consider not just the Broad Market Potential of
the project but also what sort of Broader Market
Potential we might be trading away.
Regards,
Roger
ROBERT GROW wrote:
Roger, and others:
Please see inline comments, responses to questions below.
(Again, everything is personal opinion, not RAC position.)
—Bob
I share many of Dan's concerns about
partitioning the local space.
I take Bob's point that RAC policy does not oppose the use of the CID in
addresses. In fact, I read RAC's EUI
tutorial as specifically suggesting such use:
*"A CID has the X bit equal to one and consequently that places any
address with the CID as its first three octets in the local address
space (U/L = 1)."
*"a CID can be extended to create a locally administered MAC address"
*"If a CID is used to create MAC addresses, the X bit becomes the U/L
bit. Any such addresses are by definition locally administered and
consequentially may not be globally unique."
So I think that it's difficult to justify opposition to the P802c PAR
based on RAC policy for the CID.
But the fundamental concerns remain. I'd like to get a better
understanding of what the RAC was thinking. I can't understand the
explanation in the EUI tutorial ["CID though can be a
useful
tool in management of the local address space to help a network
administrator keep local addresses unique to a network (rather than
being globally unique."]. I also don't see an
explanation in the draft 802c CSD.
<RMG>
If a vendor for example is creating virtual machines, if they use their
CID, it will by definition be unique from any other vendor using their
CID as the basis for creating local addresses for virtualization or any
other purpose. There doesn’t have to be a single address administration
function. Other thoughts of RAC members (no policy on any of this that
I recall): 1. If only a portion of the CID space is used for
automated assignment, then we can reserve another portion to be the
“wild west” where a Local Address administrator still has free reign. 2.
We can gather up and publish somehow a list of local addresses that
people have assumed to be usable. Some local addresses are specified in
standards. 3. We can consider giving priority to current OUI
assignees to get the corresponding CID (numbers only differing by the
U/L bit). This would legitimize those users that assumed (they had
rights to do this). (Big debate should we reaward someone that just
assumed rights that weren’t expressly granted?) BTW, The RAC
administrator just received a question last month stating the assumption
that they had rights to flip the U/L bit of an assigned OUI and nobody
else would be assigning a Local Address with that value—nothing that RAC
policy suggests they could assume but not uncommon.
<RMG>
What of any of this RAC thinking/discussion would be included in the
p802c draft is not an issue for the PAR, but rather for draft
development and balloting. BTW, it wasn’t only RAC thinking, but 802.1
and IETF that contributed to launching the CID recognizing possibilities
for use in automated local address creation.
I'd like to understand
the perceived role of the "Company" owning the
CID used in a
MAC address. Is it:
(a) The device manufacturer? This seems to
be like saying that every locally-assigned DHCP address in my house
should have some bits that are assigned based on the manufacturer. What
use is that? [OK, diagnosis may be a little more convenient if an OUI
happens to correspond to the name brand on the device, but that's a
trivial advantage, and it's a disadvantage for privacy.]
<RMG>
On the privacy point, a CID based address is better than an EUI used
as a MAC address as it is not repetitively used by a device (24-bits
could still effectively be random) from the snooping point of view. If
it were turned around and the CID is one used by the local address
administrator, then the local MAC address that a device is using tell
you nothing about that device. Using CID in diagnosis was not a
consideration as far as I recall either during RAC discussions or in
possible protocols I’ve heard described.
<RMG>
If there were multiple DHCP devices in your house that didn’t
communicate, that would be one way to allow both DHCP devices to not
assign duplicates. I believe Fibre Channel Over Ethernet has sufficient
specification (like DHCP) so that this would not be needed, but if the
RA assigns the appropriate CID to FCOE, then no virtulization vendor or
Internet of Things vendor would be assigning duplicates with the FCOE
application.
<RMG> There are also
possibilities that the function is more that of a software vendor,
operator or other rather than a hardware manufacturer. (Though CID use
in many of these cases is not for MAC addresses but rather for Context
Dependent Identifiers.) (b) The
local network administrator? This seems to be like
saying that every locally-assigned
DHCP address in my house should have some bits
that are unique to my house. What use is that? Local is local; what
good is making it partially global?
<RMG>
The most consistent policy for use of the local address space is that a
local address administrator would assure no duplicates were created.
That has existed since the early 1980s. IBM proposals back then
indicated a preference for only using local addresses for 802.5 (16-bit
ring number and 32-bit node number). That would have operated under
this broad rule for the local address administrator. Perhaps I’m
missing your point with the DHCP example here. (c) An operator? For
example, a
gas meter has a gas company CID and an electrical meter has a power
company CID on the same LAN. Seems like a problem better solved by
VLAN,.
<RMG>
VLAN isn’t the answer to duplicate addresses. I don’t recall VLANs
being part of RAC considerations though.
<RMG>
Where there is no standard to govern things, the CID allows private
protocols that do not have to cooperate with other protocols. Obviously
if p802c is successful, then it will be referenced by other standards
and be used by private protocols rather than just picking local
addresses for the application as is now sometimes done. CID of course
has non-address uses that can reduce the consumption of OUIs. For
example, some standards specify use of an OUI for non-address
applications. I would guess though that this was not part of your
concern here.
If I were a network
administrator, I might see value in partitioning the local space
following the IP model; in other words, on the basis on topology, so I
could make forwarding decisions on the basis of a subset of the address
and not need to store every MAC address in a switching table. But, if I
were going to implement such a system, I'd want to locally administer 46
bits, not 24.
<RMG>
Lots of possibilities here. How about 44 bits? One quadrant of the
local space for the “wild west”, one for CID based automated assignment,
one for … Realistically, the problem here is how to best accommodate
the fact that the entire space is the “wild west” today, no rules other
than some local administrator being responsible for preventing
duplicates, but reality being that some uses of the local address space
are in use. From my perspective, the RAC is really serious about not
declaring other legacy uses “illegal”, something 46-bits probably could
come closer to doing. I believe the RAC consensus is that any local
address structuring will take years to get pushed into the marketplace.
We started that by getting appropriate warning into IETF descriptions
of 802 addressing and OUI and CID. We tried to get it into the revision
of Std 802. We will work to get things tightened up in many IEEE
standards that use the OUI registry especially other IEEE standards that
use 802 addressing. But this is and will be a long process not solved
by p802c even though I believe p802c helps with a solution. Any
proposal that ignores the reality of legacy use and simply assumes local
addresses are not in use, I believe is flawed, whether that assumption
is in 802 or IETF or were to become a property of any standard that
attempts to jump into the local address space.
My
personal opinion is the primary RAC responsibility is to ensure the
viability of its registries. The two I worry about most are OUI and
EtherType. I also believe that IEEE Std 802 is the right place to
standardize 802 style MAC addresses. The two are related but there is
an important distinction in responsibilities. An IEEE 802c amendment
will have been subjected to a balloting process open to all interested
parties. A RAC policy isn’t subject to the same process.
I think that
the PAR and CSD need to provide a clear indication of the expected usage
model, articulating its advantages and disadvantages.
<RMG>
I disagree in principle. Such details are for a project to decide. To
me, is there a reasonable solution (technical and economic feasibility)
to bring structure to the local address space and make local addresses
more usable for IoT, virtulization, etc. is the requirement for
approving a PAR. Sometimes we write the PAR to standardize a solution,
but that is not IEEE-SA policy. The PAR serves as an announcement to
the world of activity being initiated to all interested parties, in
other words, a PAR to address a problem or opportunity is really what is
intended by IEEE-SA process. I’m expect I’ve overstated your position
here, and I’ll leave it to the PAR proponents to accommodate provision
of more detail.
I agree
with Adrian that a forum at the Plenary would be very helpful.
Roger
Marks
EthAirNet Associates
ROBERT
GROW wrote: I'd like to clarify/correct a couple points in Dan's email. (Personal comments, not comments from the RAC.)
1. Talking about what the CID has been historically is a bit misleading. The CID has very little history, only having been introduced this year. The RAC has never stated what it would not be used for, contrary to a possible inference from the assertion that the CID was ONLY for non-address applications. I'm not aware of any RAC statement or document that says a CID shouldn't be used for local address assignment.
2. The possibility of using a three-octet value with the U/L bit set as the base for local address assignment has a very long history independent of any RAC policy supporting the practice (nor RAC policy to prevent such practice). (Some have assumed and standards have even specified local addresses based on setting the U/L bit of an assigned OUI.)
3. The possibility for recommended practices or standards specifying use of a CID in assigning a local address was a RAC consideration in recommending to the BOG that a CID product be introduced. So, the idea underlying p802c is consistent with RAC considerations in development and introduction of CIDs.
4. I would expect RAC members (me for one) and perhaps even RAC mandatory coordination comments would object to anything in p802c that declares legacy uses "illegal". I find nothing in the p802c PAR that indicates the specifications would do this. On the contrary, all presentations I have seen for "automated" assignment of local addresses (rather than assignment by a local address administrator), except for pure randomization, recognize and deal with duplicate local address assignment These proposals recognize legacy use of the local space, and minimize the impacts of duplicate addresses on network operation.
Bob Grow
bob.grow@ieee.org
M: 858 705 1829
On Oct 6, 2014, at 11:09 PM, "Stephens, Adrian P" <Adrian.P.Stephens@INTEL.COM> wrote:
Dear EC,
Feedback from Dan Harkins. His argument makes sense to me.
I'd like to see a forum at the Plenary where this discussion can take place.
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)
Tel: +1 (408) 2397485 (mobile, USA)
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-----Original Message-----
From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@ieee.org] On Behalf Of Dan Harkins
Sent: 06 October 2014 18:27
To: STDS-802-11@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-11] Fwd: [802SEC] IEEE 802 Nov 14 Plenary - "PARs under Consideration" Posted
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Jon,
Thank you for the opportunity to comment on one of these PARs.
I have serious problems with the 802c PAR. This proposes forming a group to partition and allocate portions of the local address space (those ethernet addresses with the "local" bit set to 1). Currently the local address space has 2^46 entries in it (48 bits with local bit = 1 and broadcast/multicast = 0).
There are a number of issues with this plan.
First of all, the IEEE RAC has been assigning OUIs for years.
Historically, with an OUI an assignee also got 2^24 unique addresses assigned (an MA-L). Now the IEEE RAC is requiring first-time applicants to apply for a MA-M or MA-S first, providing 2^20 or 2^12 addresses, respectively. In any event, purchasing of an OUI gets an assignment of globally-unique addresses. Also, the IEEE RAC will sell a "company ID", or CID.
CIDs are intended for "non-address applications" such as protocol identifiers or context-dependent identifiers and assignees get a total of zero addresses, which makes sense (non-address application gets no addresses). These CIDs look just like OUIs, they are 24 bits, except if you were to construct an address out of a CID it would be in the local address space because the difference between an OUI and CID is a bit which maps to the "local" bit. This has not been a problem historically because CIDs are for "non-address applications" and you should not be forming addresses out of CIDs so there could be no conflict.
This PAR wants to allocate a portion of the local address space using IEEE RAC assigned CIDs. It actually wants to form addresses out of things that have been assigned for non-address applications. That does not seem to be consistent with the past or current practice of the IEEE RAC. And it creates new problems that IEEE RAC assignment of CIDs did not used to have, namely devices that use the local address space today may now become "illegal" as they will infringe on addresses this 802c group may allocate if the PAR is approved.
Another problems is that applications that want to randomize MAC addresses, for example following the recommendations from 11-14/0367r2, the probability of a collision of randomly-chosen MAC addresses must be kept as remote as possible. Partitioning the local address space will vastly increase the probability of collision and when there's a collision of MAC addresses on a network there are networking problems. Randomly-chosen MAC addresses do not need to be globally unique, they just need to be unique on the locally-switched network. As soon as a router is reached the addresses don't matter-- i.e. a device on the other side of the router could choose the same MAC address as my device does and that's not a problem.
Using the birthday paradox we can tell the probability of a collision p(N:C) with C being the number of MAC addresses available to choose from and N being the number of STAs on a locally-switched network. How many STAs can we expect? Well for a small IEEE/verilan kind of network it's going to be less than 5000. The record for the largest 802.11 deployment is 30,000+ simultaneous STAs seen (Levi's Stadium in Santa Clara, CA at a 49ers game).
If the entire local address space is available we get:
p(500, 2^46) = 0.0000000018
p(1000, 2^46) = 0.0000000071
p(5000, 2^46) = 0.0000001776
p(10000, 2^46) = 0.0000007105
p(30000, 2^46) = 0.00000639 (about 1:156,000)
p(64000, 2^46) = 0.0000291 (about 1:34000)
Keep in mind that modern switches don't really function too well when the forwarding table gets too big (which is why vendors recommend it not get bigger than 32k even though the theoretical max is 64k). If the 802c PAR requires randomly choosing based on a CID we end up with:
p(500, 2^24) = 0.0074
p(1000, 2^24) = 0.029
p(5000, 2^24) = 0.525
and that's already worse than a coin flip, for just 5000 STAs.
Actually, the probability of collision for an average home network with the 802c partitioning, p(15, 2^24), is about the same as it is for the largest 802.11 network ever without the 802c partitioning, p(30000, 2^46).
So this PAR will guarantee that collisions will happen constantly on even the smallest 802.11 network. This PAR will guarantee chaos on a network of any reasonable size.
To sum, this PAR will create problems with the way the IEEE RAC has historically allocated CIDs (they are for non-address purposes and you get no addresses) and it will guarantee chaos on switched networks. Well what problem does this PAR solve if it's producing all these problems you ask? It doesn't look like it solves a problem.
It says that "[i]ncreasing use of virtual machines and Internet of Things (IoT) devices could exhaust the global address space if global addresses are assigned. This project will enable protocols that automatically configure addresses from a portion of the local address space. Such protocols will allow virtual machines and IoT devices to obtain a local address without local administration."
But these devices can already automatically configure addresses from the local address space by just choosing randomly and the probability of collision is very remote. This PAR is actually describing a non-problem-- IoT devices cannot obtain local addresses without local administration-- and then proposing to create huge problems because of it-- partitioning of the local address space.
I am strongly opposed to this PAR. IEEE 802 should not be approving groups that will cause huge problems on networks, especially when they do not appear to provide any tangible benefit.
Thank you for giving me this opportunity to express my opinion on the 802c PAR. Regards,
Dan.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
|