[mpiwg-tools] Tools topics meeting reminder: Jan 19, 2017

[Jeff Squyres (jsquyres)]

I have confirmed with the IEEE Registration authority that an open source software project can purchase a CID.

Hence, the scheme listed below would seem to work well -- our (logical) vendor ID can be an IEEE OUI or CID, because they hold the desired properties:

- they are both 24 bits long
- OUIs and CIDs are guaranteed to be unique (both within their respective classes and from each other)
  - hence, a single 24-bit parameter is suitable for holding either value
- IEEE maintains a world-wide registry of both OUIs and CIDs
- purchasing a CID is not cost-prohibitive
- purchasing a CID for use in this case is appropriate for software vendors (including open source projects)



> On Feb 2, 2017, at 10:59 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
> 
> The more I look into this, the more it looks like we should use a CID and/or an OUI.
> 
> The CID and OUI are both 24-bit IEEE-maintained numbers.
> 
> CID = Company ID.  Used for no particular purpose.
> OUI = Organization Unique ID.  Used for Ethernet MAC address space reservation.
> 
> While all networking vendors in the HPC space have OUIs, researchers and software tool vendors probably do not.  We do not want researchers/software vendors to buy an OUI -- that would be a mis-use of global MAC address space.
> 
> It looks like the CID was created for exactly this purpose: you need a globally unique number, but you do not need to reserve a range in in the MAC address space.
> 
> The IEEE was clever enough to reserve 1 bit to tell the difference between an OUI and a CID.  Hence:
> 
> - all OUIs are distinct from all CIDs, and vice versa
> - if you care, you can tell if a given 24 bit value is a CID or OUI
> 
> It looks like the purchase of a CID is $685 USD: http://standards.ieee.org/develop/regauth/cid/index.html
> 
> http://standards.ieee.org/develop/regauth/tut/eui.pdf
> 
> What I don't know yet is whether an open source software project can buy a CID or not.  I have an email in to IEEE asking this question.
> 
> 
> 
>> On Feb 2, 2017, at 8:21 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
>> 
>> On Feb 2, 2017, at 7:02 AM, Marc-Andre Hermanns <hermanns at jara.rwth-aachen.de> wrote:
>>> 
>>> I did not want to mandate a specific length. The way I understand it
>>> is that the ID is an integer of some length, where parts can be masked
>>> and queried for information.
>> 
>> I think what I was trying to say (poorly) was that I am proposing a *logical* tuple.  How long each item is in the tuple, and how we map that to C types are different questions.
>> 
>> Your proposed prototype had a single uint64_t parameter; I just wanted to make sure we were still talking about a tuple, not a single (logical) value.
>> 
>>> In my last mail, yes, but I do acknowledge that additional fields are
>>> necessary. I just asked about the vendor ID, as that is the one mostly
>>> regulated, right? The vendors are free to use the remaining bits as
>>> they see fit, right?
>> 
>> I would think so.
>> 
>>> Yes, I read about the OUI. As far as I know, these are _bought_ from
>>> and controlled by IEEE. How would an MPI vendor obtain one of those to
>>> use for software events from inside the MPI?
>> 
>> Buy one.
>> 
>> -- 
>> Jeff Squyres
>> jsquyres at cisco.com
>> 
> 
> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> 
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-tools


-- 
Jeff Squyres
jsquyres at cisco.com