Re: [802SEC] FW: [STDS-802-11] Fwd: [802SEC] IEEE 802 Nov 14 Plenary - "PARs under Consideration" Posted
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.
>
> On 10/6/14 6:28 AM, "Jon Rosdahl" <jrosdahl@ieee.org> wrote:
>
>>
>>
>>
>> --- This message came from the IEEE 802.11 Working Group Reflector ---
>> This is the list of PARs that will be reviewed during the November
>> Plenary.
>> If you have comments on the PARs or the CSD files please let me know.
>> Thanks,
>>
>> Jon
>>
>> 1st Vice Chair
>>
>> IEEE 802.11
>>
>> -----------------------------------------------------------------------
>> ---
>> ---
>> Jon Rosdahl Senior Standards Architect
>> hm:801-756-1496 CSR Technologies Inc.
>> cell:801-376-6435 10871 North 5750 West
>> office: 801-492-4023 Highland, UT 84003
>>
>> A Job is only necessary to eat!
>> A Family is necessary to be happy!!
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: John D'Ambrosia <John_DAmbrosia@dell.com>
>> Date: Sat, Oct 4, 2014 at 4:39 AM
>> Subject: [802SEC] IEEE 802 Nov 14 Plenary - "PARs under Consideration"
>> Posted
>> To: STDS-802-SEC@listserv.ieee.org
>>
>>
>> All,
>> The page for ³PARs under Consideration² have been posted to include the
>> information below. See http://www.ieee802.org/PARs.shtml.
>>
>> Nov 2 - 7, 2014, San Antonio, TX, USA
>> * 802c, Amendment: Local Media Access Control (MAC) Addressing,
>>
>> PAR
>> <http://www.ieee802.org/1/files/public/docs2014/new-addresses-thaler-lo
>> cal
>> -address-par-v01.pdf> and
>> CSD
>> <http://www.ieee802.org/1/files/public/docs2014/new-addresses-thaler-lo
>> cal
>> -address-csd-v01.pdf>
>> * 802.1AS-rev - Timing and Synchronization for Time-Sensitive
>> Applications,
>>
>> PAR
>> <http://www.ieee802.org/1/files/public/docs2014/new-802-1AS-rev-draft-p
>> ar-
>> 0514-v1.pdf> and
>> CSD
>> <http://www.ieee802.org/1/files/public/docs2014/new-802-1AS-rev-draft-c
>> sd-
>> 0514-v1.pptx>
>> * 802.1Qch- Amendment: Cyclic Queuing and Forwarding, PAR
>> <http://www.ieee802.org/1/files/public/docs2014/ch-mjt-cyclic-queuing-a
>> nd-
>> forwarding-par-0914-v01.pdf> and
>> CSD
>> <http://www.ieee802.org/1/files/public/docs2014/ch-mjt-cyclic-queuing-a
>> nd-
>> forwarding-par-csd-0814-v01.pdf>
>> * 802.3bv- Amendment, 1000 Mb/s Operation Over Plastic Optical Fiber ,
>>
>> PAR <http://www.ieee802.org/3/GEPOFSG/P802_3bv_PAR_240914.pdf> and CSD
>> <http://www.ieee802.org/3/GEPOFSG/CSD_GEPOF_0914.pdf>
>> * 802.3by- Amendment: Media Access Control Parameters, Physical Layers
>> and Management Parameters for 25 Gb/s Operation,
>>
>> PAR <http://www.ieee802.org/3/25GSG/25GE_PAR_final_110914.pdf> and CSD
>> <http://www.ieee802.org/3/25GSG/25GE_CSD_0914_adopted.pdf>
>> * 802.15.7a- Amendment for a Physical Layer Supporting Optical Camera
>> Communications,
>>
>> PAR
>> <https://mentor.ieee.org/802.15/dcn/14/15-14-0601-00-007a-p802-15-7a-pa
>> r-m
>> yproject-2014-09-28.pdf> and
>> 5C
>> <https://mentor.ieee.org/802.15/dcn/14/15-14-0216-03-007a-draft-csd-for
>> -ie
>> ee-802-15-sg7a-occ.docx>
>>
>> Regards,
>> John D¹Ambrosia
>> Recording Secretary, IEEE 802 LMSC
>>
>>
>>
>>
>>
>> ---------- This email is sent from the 802 Executive Committee email
>> reflector. This list is maintained by Listserv.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________________________________
>> ___
>> _____
>> If you wish to be removed from this reflector, do not send your request
>> to this reflector - it will have no effect.
>>
>> Instead, go to
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11
>> <http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11> and then press
>> the LEAVE button.
>>
>> If there is no LEAVE button here, try
>> http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO
>> <http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO>.
>> Further information can be found at:
>> http://www.ieee802.org/11/Email_Subscribe.html
>> <http://www.ieee802.org/11/Email_Subscribe.html>
>> _______________________________________________________________________
>> ___
>> _____
>>
>
> _______________________________________________________________________________
>
> If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
>
> Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
>
> If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.
>
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
> _______________________________________________________________________________
>
> ----------
> This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.