Re: [mcnet4l-devel] eui-48 and moniker conversion.

[Mark H. <mar...@mv...>]

Hi, Daniel, et al..

We fixed the byte ordering, although it would be incorrect to refer to it as
big endian or little endian, since the moniker is a string of octets, and not a
number.

I read the info at http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
and you are correct, the encapsulation in the spec is incorrect, and, in fact,
violates IEEE guidelines for encapsulation.  While it works as is, the IEEE
holds trademark and copyrights to the use of this forma, and we are not in
compliance.

Sean, how do we want to handle an erratum of this type?  Can we publish a
notice on the PICMG website?  The change is that the MAC-48 to EUI-64
encapsulation uses FFFF rather than FFFE as the extension sequence.  While the
extension from EUI-48 to EUI-64 given in the 2.14 spec is correct, the value we
need to extend is a MAC-48.  An EUI-48 is not a hardware class instance, but
rather the class itself.  But the MAC-48 is the instance address, which is what
we need to extend.

Mark Huth

Daniel Stodden wrote:

> hi "all" :)
>
> first of all, i noticed yesterday that somewhere between D0.64 and
> D1.0 the moniker byte order has been reverted to true EUI-64 byte
> ordering (big endian) as opposed to the rest of binary number formats
> being le.
>
> whoever proposed this: thank you, good idea (no kidding). makes my
> day.
>
> second, an issue regarding 48/64-bit conversions:
>
> the following is taken from
> http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html
> (i must admit i actually never read that page before)
>
> * MAC-48: A 48-bit identifier used to address hardware interfaces
>   within existing 802 based networking applications
> * EUI-48: A 48-bit identifier used to identify a design instance, as
>   opposed to a hardware instance. Examples include software interface
>   standards (such as VGA) or the model number for a product.
> * EUI-64: A 64-bit identifier used to identify each hardware instance
>   of a product, regardless of application, such as wireless devices
>   and computerized toasters.
>
> while the difference between MAC-48 and EUI-48 is pretty zero
> regarding the resulting addressing scheme, the above statement makes
> 2.14 appear to me rather as a MAC-48 application than EUI-48.
> Ok, the question whether 2.14 is 802 based is definition dependant,
> but a moniker is definitely not a design instance as defined above.
>
> Why I care? 48-bit encapsulation:
>
>    ccccccFFFEeeeeee16   (an EUI-48 extension)
>
>    ccccccFFFFeeeeee16   (a MAC-48 extension)
>
> from this standpoint the encapsulation scheme described in 2.14
> chapter 3.1, defining a fill sequence of ff:fe would be wrong.
>
> assuming to be right here: i'm not sure about the implications. As
> long as everybody is coding along the picmg spec and does not look
> into ieee documents, this certainly does not break interoperability on
> the backplane. any 'theoretical' danger when bridging into 802.x LANs
> or stuff like that?
>
> regards,
> dns
>
> --
> ___________________________________________________________________________
> mailto:st...@in...
>
> _______________________________________________
> mcnet4l-devel mailing list
> mcn...@li...
> http://lists.sourceforge.net/lists/listinfo/mcnet4l-devel