Re: GID clarifications

Yes, the port's GUID is the manufacturer assigned EUI-64 id for the port. It is
probably better to use the IBA term 'portGUID'.

Vivek

On Wed, 3 Dec 2003, Kanoj Sarcar wrote:

> Vivek Kashyap wrote:
> >
> > Kanoj,
> >
> > The port's GUID is it's EUI-64 identifier. A GID, in turn can be formed using this GUID, the CA's GUID or some other value. Any GID is unique in the IB fabric however only by using the port's GUID/EUI-64 identifier can one uniquely identify the port. The other GID's, as noted, can be applied to other ports too - though not concurrently. The GID formed using the EUI-64 identifier is the 'GID at index 0'. I've made note of your comment and can clarify further as needed.
> >
> > wrt, using only GID at index 0 as in the MAC address, there have been proponents of using the other GIDs (non EUI-64 GID).
> >
> > Vivek
>
> Vivek,
>
> Per IBA 1.1 section 4.1 EUI-64 subsection and 4.1.1 item 2, manufacturer assigned and
> SM assigned values are required to be EUI-64 compliant (they differ only in u/l bits).
> Thus, all GIDs contain an EUI-64 in the lower 64 bits; thus saying "GUID is its EUI-64
> identifier" might be confusing. Saying "GUID using manufacturer assigned EUI-64 identifier"
> or better "GID index 0" removes all confusion. I think we agree on the intent, I just
> want to make sure if you use the term GUID, you do specifically define what you mean
> by it.
>
> Regarding MUST vs RECOMMENDED, is it worthwhile reconsidering given that
>
> 1. SM assigned GIDs are not that popular (anymore?)
> 2. it allows determination of sender's ipoib address, thus allowing (receiver side)
> implementations to be dlpiv2 conformant?
>
> Thanks.
>
> Kanoj
>
>
>
> > --
> > Vivek Kashyap
> > Linux Technology Center, IBM
> > [email protected]
> > [email protected]
> > Ph: 503 578 3422 T/L: 775 3422
> >
> >     Kanoj Sarcar <[email protected]>
> >     Sent by: [email protected]
> >
> >     12/02/2003 03:54 PM
> >     Please respond to Kanoj.Sarcar
> >
> > Hi,
> >
> > It seems that certain parts of the
> > draft-ietf-ipoib-ip-over-infiniband-05.txt draft might
> > require clarification. For this discussion, please refer to
> >
> > 1. section 9.1 Link Information says:
> > "The GID, if formed using the GUID, can be used to unambiguously
> > identify an endpoint."
> >
> > 2. section 9.1.1 Link Layer Address/Hardware Address, part c) says:
> > "It is RECOMMENDED that the GID formed by the combination of the
> > IB subnet prefix and the port's GUID be included in the
> > link-layer/hardware address."
> >
> > Can comment #2 be safely taken to mean that GID index 0 is
> > being RECOMMENDED? Port GUID seems somewhat ambiguous, since I
> > am not sure (after reading IBA 1.1 section 4.1) whether the
> > term GUID refers only to the manufacturer assigned value that appears
> > in lower 64 bits of GID index 0, or whether it also includes
> > lower 64 bits of SM assigned GIDs at higher indices. If GID index 0
> > was really intended, the comment should explicitly state so to prevent
> > confusion.
> >
> > Also, to make things simple, is it reasonable to REQUIRE implementations
> > to always use GID index 0 (maybe this depends on whether existing
> > implementations all use GID0 only)? The reason this might be
> > interesting is that when a node receives a packet without a GRH
> > (whereby it already knows the sender's LID and QPN), it can possibly
> > reverse lookup the sender's LID to identify the sender's GID index
> > 0 and concatenate the sender's QPN to figure out the sender's link
> > address. Thus, a receiver can always figure out the sender's address,
> > even when a GRH is not present. This would be similar to ethernet,
> > where a receiver can always determine a sender's address, and thus
> > is more DLPIv2 (unitdata_indication) friendly.
> >
> > Regarding comment #1, what does "unambiguously identify an endpoint"
> > mean? GIDs are unique in the subnet; and if an IP link contains
> > members in multiple IBA subnets, the subnet prefixes will disambiguate
> > which endport is being referred.
> >
> > Thanks.
> >
> > Kanoj
> >
> > _______________________________________________
> > IPoverIB mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/ipoverib
>
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
>
>

__

Vivek Kashyap
Linux Technology Center, IBM