Subject: Re: [Ipoverib] DHCP over InfiniBand

From: Vivek Kashyap <[email-masked]>
Date: Tue, 2 Apr 2002 16:25:23 -0800 (PST)

> Back to the client-identifier.  Although I don't believe this was your
> intent, Section 2.1.1 gives the impression that the draft is specifying
> fixed length format.  I suggest changing the language of the first sentence
> from "The format.... is as defined below" to "A suggested format....".
> Perhaps the section title should be changed to "Considerations for using HW
> address as client-identifier".

But isn't a fixed length setup better ? It goes with the type. The
client identifier can be set to anything a host desires but if it is
set to type 32(InfiniBand) the length is 20 bytes. For those nodes
that don't have any use of the 4 bytes of 'interface-id' the field can
be set to zero. Note that a host can also use FQDN, EUI64 or any other
well-defined type suitable for its needs.

Vivek

> 
> Roy
> 
> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]]
> Sent: Tuesday, March 26, 2002 6:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ipoverib] DHCP over InfiniBand
> 
> 
> Roy,
>         The DHCP server needs a value by which it can uniquely
>         identify the client. This uniqueness is certainly satisfied by
>         the use of the IPoIB link address. 
> 	
>         The server records this unique identifier in its database. But
>         for the server to be able to utilise this information across
>         client boots the client must present the same identifier to
>         it; hence the suggestion of invariance of the
>         client-identifier. 
> 
>         If the chaddr field is used and the client-identifier is not
>         used, then too the same 'chaddr' field must be presented to
>         the server to ensure the server can recognise the client.
> 
>         Note that this issue is of prominence here only because there
>         maybe multiple IPoIB interfaces associated with the same GID.
>         An EUI-64 value or the GID will do otherwise. If you plan to
>         use only one IPoIB interface per GID then there is really no
>         issue - just use the GID.
> 
>         If the IPoIB link address was equal or less than 16-bytes then
>         we wouldn't have to use the Broadcast bit. 
> 
> Vivek
> 
> > 
> > Vivek,
> > 
> > This looks good.  Thanks.  I do have one question.  I assume that the
> > "invariantness" of the interface-id would also apply to the chaddr if that
> > were available to us.  Does this mean that if the IPoIB hardware address
> > were <= 16 bytes and contained the QPN that it would still be unusable for
> > DHCP?  What I'm trying to get at is, why can't we just say the
> > client-identifier IS the IPoIB hardware address found in an ARP?  Is the
> > "variantness" of the hardware address acceptable in ARP but not in DHCP?
> > The asymmetry concerns me and I just want to make sure there are no
> > stumbling blocks down the road related to the variant nature of the IPoIB
> > hardware address.
> > 
> > Roy
> > 
> > -----Original Message-----
> > From: Vivek Kashyap [mailto:[email-masked]]
> > Sent: Tuesday, March 26, 2002 3:38 PM
> > To: [email-masked]
> > Subject: [Ipoverib] DHCP over InfiniBand
> > 
> > 
> > I submitted the following draft based on the discussions we had on the
> > mailing list and at the IETF meeting. It doesn't appear to me that we
> > are moving in the direction of shortening the link-layer address. So
> > the 'broadcast bit' is the solution.
> > 
> > Please comment.
> > 
> > Thanks
> > 	Vivek
> > 
> > <snip>
> > 
> > _______________________________________________
> > 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
> 
> 

-- 
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: "Jim Pinkerton" <[email-masked]>
Date: Wed, 3 Apr 2002 16:55:07 -0800

I'm also confused with why the parameter specified in the client id
should not be opaque. My understanding of the DHCP spec is that the
server is *required* to view the content as opaque.  Thus I don't
understand the value in specifying the content, or its length.

Jim

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

> 
> > /rkl
> > NO!  Isn't that how we got here?  If DHCP hadn't defined the
'chaddr' as
> > fixed length we wouldn't even be having this discussion.  The
> > client-identifier is an opaque value so why should the length
matter?
> > rkl/
> 
>         chaddr applies to all hardware types. The value 32 applies to
>         InfiniBand. The choice is between listing the hardware address
>         or just the GID. I prefer the full hardware address -
>         including the QPN. Now, for those that don't have a constant
>         QPN and whose uniqueness requirement is served by just the GID
>         can set the 4 bytes of QPN/reserved flags to 0.
> 
>         The length in the option field therefore automatically becomes
>         21 since we need to add the 1 byte of hardware type.
> /rkl
> Since the QPN is an output parameter of the CREATE QUEUE PAIR verbs
> interface, I don't believe anyone should assume an invariant QPN.

        It is not 'assume an invariant QPN' but 'know the invariant
        QPN' i.e. if the implementation ensures invariant QPN it can
        use it. Verbs don't restrict anyone from implementing an
        interface that returns a specific queue pair or any other
        solution that allows for invariant QPs for a particular
        function. This is not the issue though.

        I suppose the length can be a different fixed length - but
        then, as you too seem to agree below, one can just use type 0
        for a non-htype client id.

> 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 ?

Vivek

> 
> Thanks for clarifying the type usage in DHCP.
> Roy
> rkl/
> 
> <snip>
> 
> Vivek
>

---

From: "Larsen, Roy K" <[email-masked]>
Date: Thu, 4 Apr 2002 12:20:21 -0800

Thanks Vivek.  I think the flow and clarity of this section is much better
now.

Roy 

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Thursday, April 04, 2002 10:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ipoverib] DHCP over InfiniBand

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

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