Re: GID clarifications

Ajoy,

I concur with your suggestions.

Vivek




On Wed, 3 Dec 2003, Ajoy C Siddabathuni wrote:

>
> ! From: Vivek Kashyap <[email protected]>
>
> ! 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'.
>
> yes, it seems to be sufficient to just reword GUID to something like
> "portGUID(EUI-64)".
>
> Note that there is slight ambiguity in the way GID0 is defined in 4.1.1 of
> the spec; which is why I dont prefer changing the wording to "GID0" in the rfc.
>
> <snip>
> "...This GID is referred to as GID index 0 and is formed by techniques 3(a)
> and 3(b) described below."
> ^^^
>
> 3(a) talks about how GID0 is formed with default-prefix(fe80)::EUI64
> 3(b) talks about how GID0 is formed with subnet-prefix::EUI64
> 3(c) talks about GIDs 1 and above.
>
> So its better to leave the "IB subnet prefix" part of the GID definition in
> the rfc(9.1.1) and just reword "GUID" to "portGUID(EUI-64)". That way an
> endpoint does provide the GID0 formed with IB subnet prefix when available.
> If the IB subnet prefix also happens to be the default-prefix, that's life.
>
> As far as RECOMMENDED vs. MUST, going by the IETF standards, RECOMMENDED is
> compelling enough for implementors to follow it blindly, still leaving room
> for some clever implementations.
>
> <snip>
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>
> thx,
> ~Ajoy
>
> !
> ! 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
> !
> !
> ! _______________________________________________
> ! 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