bill | 4 May 17:12 2004
Picon

60th IETF Meeting in San Diego

It is time to start taking scheduling requests for the 60th IETF
meeting.

I would be interested in hearing implementation reports on IPoIB
implementations, MIB updates, DHCP and any other topics that people
would like to present.  There is also an interop test for the end of
August being planned - more details when they are available.

If you have an IPoIB implementation and would like a slot, please
contact me and I will get you time on the schedule

Bill

I am training for my first endurance event... and SAVING lives click
here to find out more!
http://www.teamintraining.org/participant/strahm-163543
bill | 4 May 17:14 2004
Picon

RE: Last Call for DHCP Draft

In looking over my mail - I realize that I have never officially closed
this WG Last call.  I have received no issues with this draft and will
ask the Margaret (Our IESG AD) to take to the IESG.

Bill

I am training for my first endurance event... and SAVING lives click
here to find out more!
http://www.teamintraining.org/participant/strahm-163543

-----Original Message-----
From: ipoverib-admin <at> ietf.org [mailto:ipoverib-admin <at> ietf.org] On Behalf
Of bill <at> strahm.net
Sent: Monday, March 29, 2004 9:48 AM
To: ipoverib <at> ietf.org
Subject: [Ipoverib] Last Call for DHCP Draft

Thank you all for helping get the IP Encapsulation drafts to the IESG.
Now that they are in the IESG's hands Jerry and I would like to start
the Working Group Last Call for DHCP over Infiniband.

Please take the next two weeks to review
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-dhcp-over-infiniban
d-06.txt
and return comments to the working group so we can pass this document
off to the IESG as well.

Thank you
Bill & Jerry
IP over IB co-chairs
(Continue reading)

Internet-Drafts | 6 May 17:26 2004
Picon

I-D ACTION:draft-ietf-ipoib-architecture-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over InfiniBand Working Group of the IETF.

	Title		: IP over InfiniBand(IPoIB) Architecture
	Author(s)	: V. Kashyap
	Filename	: draft-ietf-ipoib-architecture-04.txt
	Pages		: 24
	Date		: 2004-5-4
	
	InfiniBand is a high speed, channel based interconnect between
        systems and devices.

        This document presents an overview of the InfiniBand
        architecture. It further describes the requirements and
        guidelines for the transmission of IP over InfiniBand.
        Discussions in this document are applicable to both IPv4 and
        IPv6 unless explicitly specified. The encapsulation of IP over
        InfiniBand and the mechanism for IP address resolution on IB
        fabrics are covered in other documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-architecture-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
(Continue reading)

bill | 6 May 20:07 2004
Picon

RE: I-D ACTION:draft-ietf-ipoib-architecture-04.txt

Vivek has made a few clarifying chagnes around the phrases that IPv6 addresses are used as IB addresses that the
IESG asked for.

Please look this over and make any comments  by next Thursday (May 13th) so it can be resubmitted back to the
IESG for approval

Bill Strahm
co-chair
> -------- Original Message --------
> Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-architecture-04.txt
> From: Internet-Drafts <at> ietf.org
> Date: Thu, May 06, 2004 8:26 am
> To: i-d-announce <at> ietf.org
> Cc: ipoverib <at> ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP over InfiniBand Working Group of
> the IETF.
>
> 	Title		: IP over InfiniBand(IPoIB) Architecture
> 	Author(s)	: V. Kashyap
> 	Filename	: draft-ietf-ipoib-architecture-04.txt
> 	Pages		: 24
> 	Date		: 2004-5-4
>
> 	InfiniBand is a high speed, channel based interconnect between
>         systems and devices.
>
>         This document presents an overview of the InfiniBand
(Continue reading)

The IESG | 18 May 00:14 2004
Picon

Document Action: 'IP over InfiniBand(IPoIB) Architecture' to Informational RFC

The IESG has approved the following document:

- 'IP over InfiniBand(IPoIB) Architecture '
   <draft-ietf-ipoib-architecture-04.txt> as an Informational RFC

This document is the product of the IP over InfiniBand Working Group. 

The IESG contact persons are Margaret Wasserman and Thomas Narten.

Technical Summary

InfiniBand is a high speed, channel based interconnect between
systems and devices.

This document presents an overview of the InfiniBand
architecture. It further describes the requirements and
guidelines for the transmission of IP over InfiniBand.
Discussions in this document are applicable to both IPv4 and
IPv6 unless explicitly specified. The encapsulation of IP over
fabrics are covered in [IPOIB_ENCAP] and [IPOIB_DHCP].

Working Group Summary

This document is a work item of the IPOIB WG.

Protocol Quality

 This document was reviewed for the IESG by Margaret Wasserman.
H.K. Jerry Chu | 23 May 21:22 2004
Picon

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-infiniband-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
(Continue reading)

Diego Crupnicoff | 24 May 03:44 2004

RE: please read: Clarification on GUID's universal/loc al bit

Resending...

> -----Original Message-----
> From: Diego Crupnicoff
> Sent: Sunday, May 23, 2004 10:12 PM
> To: 'H.K. Jerry Chu'; ipoverib <at> ietf.org
> Cc: daniel.cassiday <at> sun.com; narten <at> us.ibm.com;
> bill <at> strahm.net; margaret <at> thingmagic.com
> 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:Jerry.Chu <at> eng.sun.com]
> > Sent: Sunday, May 23, 2004 4:22 PM
> > To: ipoverib <at> ietf.org
> > Cc: daniel.cassiday <at> sun.com; narten <at> us.ibm.com;
> > bill <at> strahm.net; margaret <at> thingmagic.com
> > 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
> >
> > jerry.chu <at> sun.com
> > Sr. Staff Engineer
> > Solaris Networking & Security Technology
> > Sun Microsystems, Inc.
> > (650) 786-5146
> >
> >
> > _______________________________________________
> > IPoverIB mailing list
> > IPoverIB <at> ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
> >
>

Margaret Wasserman | 24 May 04:51 2004

RE: please read: Clarification on GUID's universal/loc al bit


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
Diego Crupnicoff | 24 May 14:14 2004

RE: please read: Clarification on GUID's universal/loc al bit

Hi Margaret,

> (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.

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

Daniel Cassiday | 24 May 23:28 2004
Picon

Re: please read: Clarification on GUID's universal/loc al bit

The IBTA link WG (who is responsible for this mess in the first place) 
has discussed this issus and is exploring solutions.

The current thinking is not to use the u bit to indicate global scope. 
Instead, any locally administered IB addresses (i.e. IB 64-bit Global 
identifiers) would use a reserved vendor identifier (i.e. a reserved 
OUI).  Any IB 64-bit Global ID that does not use this vendor tag will 
have global scope and be globally unique.

In this approach, the IBTA would apply to the IEEE Registration 
Authority for a OUI to be used for this purpose. The IBTA would also 
clarify the IBA spec and add the requirement the "u" bit is ignored in 
the EUI-64 (i.e. a vendor cannot have two EUI-64s differing only in the 
value of the "u" bit)

Diego Crupnicoff wrote:
> Hi Margaret,
> 
>  > (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.
> 
> 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
> 

Gmane