Subject: RE: [Ipoverib] DHCP over InfiniBand

From: "Larsen, Roy K" <[email-masked]>
Date: Tue, 2 Apr 2002 17:17:08 -0800

/rkl
embedded
rkl/

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

> 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.
/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/
                                                                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.
/rkl
Since the 'interface-id' must be invariant when needed, I would like to see
a bigger field so that I can use an ASCII string value.  So, if it must be
fixed length, I would like to see an 'interface-id' of no less than 16
bytes.
rkl/
                 Note that a host can also use FQDN, EUI64 or any other
well-defined type suitable for its needs.
/rkl
This is probably showing my ignorance of DHCP.  If I used FQDN, EUI64, etc.,
would I use a different type value than 32?  RFC2131 implies this should be
a hardware type defined in RFC1340.  In the draft you've posted, how should
I interpret the last paragraph of section 2.1 that says "'client identifier'
option MAY consist of any data.?

Roy
rkl/

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

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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 3 Apr 2002 12:27:27 -0800 (PST)

> client-identifier is an opaque value so why should the length matter?

        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.

> fixed length, I would like to see an 'interface-id' of no less than 16

        If you want to use some arbitrary data then use the type value
        of 0. 

> option MAY consist of any data.?

        Yes, you need to use a different type. 27 for EUI64, 0 for
        FQDN or other arbitrary data. See RFC2132, section 9.14.

        Also, RFC1340 has long been obsoleted. Look under 'ARP
        parameters' at www.iana.org.

Vivek