RE: GID clarifications

Michael Krause <[email protected]>
Newsgroups gmane.ietf.ipoib
Message-ID <[email protected]>
At 06:04 PM 12/4/2003 -0800, bill wrote:
>Ok, let me ask a few questions to lead us toward concensus

As the author of the IB spec for chapter 4, I'll attempt to provide some 
clarifications.

>1) Does anyone give a compelling reason to use anything but GID0 for IPoIB 
>- what is the benefit of doing this ?

Multiple GIDs were provided as a method to:

- Provide traffic segregation between subnets conceptually similar to 
multi-LID usage within a single subnet.

- Provide a method to support software / OS virtualization and device 
sharing via using a unique global identifier independent of the number of 
LIDs assigned (though one can take a similar approach if the LMC value is 
greater than 0.

I will note that there are many OSVs offering or starting to offer 
virtualization services and while some initial implementations may be 
focused on GID 0, this may not hold true in the coming few years.

- Provide a method to constrain out some data flows are routed - local vs. 
non-local subnet access given a GID can use either the default or the SM 
assigned subnet prefix.

>2) Does anyone have an implementation that uses anything but GID0 for IPoIB ?

I believe it would be a mistake to limit support to just GID 0.  IB 
technology was designed to support a diverse set of usage models that will 
evolve over time.  The only potential problem was a DLPI application raw 
level usage model which is (a) somewhat outside of the scope of the IP over 
IB specification and (b) rather limited in terms of usage within the 
industry.  I don't really want to debate the merits of raw DLPI but do 
acknowledge it is in use today on Ethernet and other layer 2 interconnects.

>If I do not hear any counter arguments by next Friday - I would like to 
>ask for concensus on MUST use GID0

Please consider this a counter argument and a vote against such a movement.

Mike
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.