Subject: RE: [Ipoverib] please read: Clarification on GUID's universal/loc al bit

From: Diego Crupnicoff <[email-masked]>
Date: Sun, 23 May 2004 18:44:10 -0700

Resending...

> -----Original Message-----
> From: Diego Crupnicoff 
> Sent: Sunday, May 23, 2004 10:12 PM
> To: 'H.K. Jerry Chu'; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [Ipoverib] please read: Clarification on GUID's 
> universal/local bit
> 
> 
> The IB spec is somewhat problematic on this issue. The spec 
> does state that global scope is obtained by setting the "u" 
> bit, but at the same time defines the IB GUID as an "IEEE 
> EUI-64 identifier" and refers to its spec for details (where 
> global scope is defined to be achieved by clearing the "u" bit).
> 
> We know of deployed IB implementations where the "u" bit in 
> the GUID is cleared.
> 
> The IBTA LWG has discussed this matter but no formal 
> resolution has yet been voted. The LWG is looking for a way 
> to solve the problem without affecting any existing implementation.
> 
> Given the above, I would suggest that IPoIB should define the 
> way to derive an IPv6 interface identifier from an 
> IB-port-GUID without making any assumptions on the value of 
> its "u" bit.
> 
> Thanks,
> 
> Diego
> 
> 
> 
> > -----Original Message-----
> > From: H.K. Jerry Chu [mailto:[email-masked]]
> > Sent: Sunday, May 23, 2004 4:22 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Subject: [Ipoverib] please read: Clarification on GUID's 
> > universal/local bit
> > 
> > 
> > A question was raised during the IESG review of the
> > encapsulation and multicast draft
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-i
> > nfiniband-06.txt
> > 
> > regarding the use of GUID as an interface identifier.
> > 
> > IPv6 spec (RFC2373 and RFC3513) requires, when an interface
> > identifier is derived from an IEEE EUI-64 identifier, that 
> > the universal/local bit to be inverted. The following is 
> > quoted from RFC3513:
> > 
> > "Modified EUI-64 format interface identifiers are formed by
> > inverting the "u" bit (universal/local bit in IEEE EUI-64 
> > terminology) when
> > forming the interface identifier from IEEE EUI-64 
> > identifiers.	In
> > the resulting Modified EUI-64 format the "u" bit is set to 
> > one (1) to indicate global scope, and it is set to zero (0) 
> > to indicate local scope."
> > 
> > IBA spec Vol1 Release 1.1 Nov 6, 2002, section 4.1 states
> > 
> > EUI-64: IEEE defined 64-bit identifier...
> > 
> > 
> > *	The universal/local bit in IEEE EUI-64 shall be set to one to
> > 	indicate global scope or set to zero to indicate local scope.
> > 	The manufacturer assigns an EUI-64 with global scope set. A SM
> > 	may assign additional EUI-64 with local scope indicated.
> > 
> > According to Dan Cassiday, the IBTA LWG chair, the above
> > paragraph clearly implies that a GUID has the universal/local 
> > bit inverted already from an EUI-64 identifier, and thus can 
> > be readily used as an IPv6 interface identifier.
> > 
> > I'd like to hear, especially from those IB hardware
> > manufacturers, if the above is consistent with your 
> > implementation. That is, the GUIDs you provide will have 
> > universal/local bit set to 1.
> > 
> > Separately if you think the IBA spec should be made more
> > clear above the relation between GUID and EUI-64, you should 
> > submit your suggestion to IBTA.
> > 
> > Thank you,
> > 
> > Jerry
> > 
> > IPoIB WG co-chair
> > 
> > [email-masked]
> > Sr. Staff Engineer
> > Solaris Networking & Security Technology
> > Sun Microsystems, Inc.
> > (650) 786-5146
> > 
> > 
> > _______________________________________________
> > IPoverIB mailing list
> > [email-masked] https://www1.ietf.org/mailman/listinfo/ipoverib
> > 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 23 May 2004 22:51:36 -0400

Hi Diego,

At 5:56 PM -0700 5/23/04, Diego Crupnicoff wrote:
We know of deployed IB implementations where the "u" bit in the GUID 
is cleared.

The IBTA LWG has discussed this matter but no formal resolution has 
yet been voted. The LWG is looking for a way to solve the problem 
without affecting any existing implementation.

Given the above, I would suggest that IPoIB should define the way to 
derive an IPv6 interface identifier from an IB-port-GUID without 
making any assumptions on the value of its "u" bit.

Given the apparent ambiguity in the IB specification, there are only 
two things that I can think of to do in this situation:

(1) Ask the IBTA to clarify their specification, with the hope that 
vendors will  update their implementations to match the clarified 
value.  It seems unlikely, though, that this is a practical choice if 
vendors have already shipped hardware that has burned-in values with 
different interpretations of the "u" bit.

-or-

(2) Accept that we cannot tell, by looking at an IB GUID, whether it 
is of global or local scope.  In this case, the conservative choice 
would be to treat all IB GUIDs as if they are of local scope, always 
clearing the "u" bit in the IPv6 IID, regardless of how the bit is 
set in the IB GUID.

There is a potential downside to choice (2):  If we do come up with 
mechanisms that can take advantage of the fact that some IIDs are 
globally unique (to simplify routing, host identification, etc.), 
those mechanisms would not work on IB nodes.  However, I can't think 
of any other practical choice.

What do others think we should do here?

Margaret

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Diego Crupnicoff <[email-masked]>
Date: Mon, 24 May 2004 05:14:53 -0700

Hi Margaret,

> clearing the "u" bit in the IPv6 IID, regardless of how the bit is 

I think it may actually be safe to assume that the IB GUID in question is
__always__ globally unique (regardless of the value in its "u" bit). The IB
spec says: 

"The manufacturer assigns an EUI-64 __with_global_scope_set__"

The IPv6 IID can therefore be based on this manufacturer assigned GUID which
is __required__ by the IB spec to be one with global scope. The mechanism
for building the IPv6 IID could then be as simple as taking the IB mfg
assigned GUID and set (if it was not already so) its "u" bit (i.e. ignore
the interpretation that the vendor may have given to the IB spec).

To close the loop, the IBTA would have to explicitly forbid the use of the
same 63 bit combination with two different values for the u bit as two valid
globally unique GUIDs. I can't speak for the entire IBTA but it looks to me
that this would be acceptable. Furthermore, it is my understanding that the
definition of locally unique IB GUIDs would then be irrelevant to the ipoib
spec.

Does it make sense?

Thanks,

Diego