Subject: RE: [Ipoverib] DHCP over InfiniBand

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 3 Apr 2002 17:17:38 -0800

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 4:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Ipoverib] DHCP over InfiniBand

<snip>

> Therefore, I would venture to guess that the client-identifier will rarely
> reflect the true IPoIB hardware address.  Since it is an opaque value and
> there is no requirement that it reflect the IPoIB hardware address, it
> doesn't follow that it must be equal in length.  But, given that I can use
> type 0 to construct a friendly invariant client-id, there is no reason to
> push it any further here.

        Agreed. Does this mean you are ok with the description in the
        draft ?
/rkl
I still believe the language is somewhat ambiguous when one considers the
last paragraph of 2.1 followed by the first paragraph of 2.1.1 followed by
the last paragraph of 2.1.1.  It leaves the reader asking what is the
purpose of section 2.1.1. if the actual format of the client-identifier does
not affect IPoIB conformance.  Nevertheless, I can accept it as it is if you
see if differently.

Roy
rkl/

Vivek

> 
> Thanks for clarifying the type usage in DHCP.
> Roy
> rkl/
> 
> <snip>
> 
> Vivek
> 
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 
> 

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

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

---

From: Vivek Kashyap <[email-masked]>
Date: Thu, 4 Apr 2002 10:39:38 -0800 (PST)

> not affect IPoIB conformance.  Nevertheless, I can accept it as it is if you

I see your point. I have added some detail to make things clear. 

Modified excerpt:

----------------------------------

        The DHCP protocol states that the 'client identifier' option
        may be used as the unique identifying value for the client.
        This value must be unique within the subnet the client is a
        member of. 
        
        The client identifier option includes a type and identifier
        pair. The identifier included in the client-identifier option
        may consist of a hardware address or any other unique value
        such as the DNS name of the client. When a hardware address is
        used, the type field should be one of the ARP hardware types
        listed in ARPPARAM. A type of 0 (zero) should be used when the
        included identifier is other than a hardware address.
        [RFC2132] 

        The client-identifier itself SHOULD not be interpreted by the
        server. [RFC2132] 

2.1 IPoIB specific usage of DHCP message fields

        A DHCP client, when working over an IPoIB interface, MUST
        follow the following rules:

	'htype' (hardware address type) MUST be 32 [ARPPARAM]

	'hlen' (hardware address length) MUST be 0.

        The 'chaddr' (client hardware address) field MUST be zeroed.
        The server and the relay agent MUST ignore 'chaddr' on
        receipt. 

        The 'client identifier' option MUST be used in DHCP messages.
        The client-identifier may consist of any data.
	
        IPoIB clients SHOULD use the following format for the
        client-identifier option:

    Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
   |  61 | 21  |  32 |Interface-id (4 bytes) |   GID (16 bytes)          |
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+

        Every IPoIB interface is associated with an identifier
        referred to as the GID [IPoIB_ARCH]. The GID is unique in the
        InfiniBand fabric. An invariant GID is formed by appending the
        port's EUI-64 identifier to the InfiniBand subnet prefix.

        The GID is associated with a particular hardware port. The GID
        and a QPN define an IPoIB interface at the port. Therefore an
        implementation may associate multiple IPoIB interfaces on the
        same port. It is up to the implementation to ensure a unique
        client-identifier when multiple IPoIB interfaces are defined
        over the same port and same GID. A unique, invariant
        'interface-id' value be included in addition to the GID to
        achieve this.

        Note: a port may be associated with multiple GIDs. Therefore,
        multiple IPoIB interfaces may exist on the same port while
        using a different GID from among the GIDs associated with the
        port. 

        A unique interface-id may be formed by including the QPN
        associated with the relevant IPoIB interface if the
        implementation is designed to keep this association constant
        across boots. A timestamp or some other value unique to the
        implementation may also be used for the same purpose.

        If there is only one IPoIB interface associated with a
        particular GID, then use of the GID with the 'interface-id'
        zeroed is sufficient. By default, an implementation zeroes out
        the interface-id field in the client identifier described
        above. 

        This document does not preclude the use of other 'client
        identifier' type, such as fully qualified domain name(FQDN) or
        the EUI-64 value associated with the interface.

-------------------------------------------------------------------

Vivek