RE: SLP, iSNS, and iSCSI

[Black_David@emc.com]

Josh,

> I'm not a DHCP expert, but in my limited understanding
> of the protocol, the DHCP server is not intelligent
> about who is asking for IP addresses and options.
> There is nothing to identify or authenticate a DHCP
> client making a request (other than the MAC), since it
> doesn't even have an IP address, not to mention an FQDN
> or any other identity.

I'm not a DHCP expert either, so we may need to go find one.
The following is what I currently understand ...

I agree with the concern about the scenario in which the
DHCP server is dynamically allocating IP addresses ...

> If this is true, I am puzzled as to how you can use
> DHCP to manage SLP scopes.  The DHCP server can't say
> "device A gets scopes X, Y, and Z", since it doesn't
> even know who device A is.  All it can do is hand out
> the same set of scopes to everyone requesting option 79.
> And that's all.  So how can you configure a complex set
> of overlapping scopes using a DHCP server???

There are at least two existing answers to that question,
both of which involve doing something different to assign
IP addresses:

(1) Manual Allocation.  From Section 1 of RFC 2131:

   In "manual allocation", a client's IP
   address is assigned by the network administrator, and DHCP
   is used simply to convey the assigned address to the client. 

In other words, the client's IP address is bound to its MAC,
and possibly additional information, such as the subnet on
which that MAC is presented if a DHCP proxy is involved.
A DHCP proxy gets around DHCP's use of link-level broadcasts
that don't propagate through layer 3 (IP) forwarding by proxying
the node issuing the broadcast to the DHCP server.  The
DHCP server can see the proxy identity, and hence knows
which subnet is involved.

(2) DHCP can be used to distribute configuration information
without doing any IP address allocation.  This is described
starting in Section 3.4 of RFC 2131, and uses a different
DHCP message from the one used to request IP address
allocation. In particular, a DHCP sever receiving such a
message  "MUST NOT check for an existing lease"
(on the IP address).

Even in the dynamic allocation scenario, knowledge of the
subnet/proxy involved may be enough for the DHCP
server to figure out what the right config parameters
are (e.g., all FCIP devices on the same subnet may be in
the same SLP scope(s), i.e., intended to connect to the
same set of FCIP peers).

> Lastly, I want to make sure everyone understands that
> support for FCIP is included in the iSNS out of courtesy
> to the FCIP community, and after close consultation with
> several key individuals from that community.  Since we
> are not implementing FCIP, I personally am neutral on
> whether it should be used for FCIP, although I do
> believe it would be of great value.

I believe I was also a source of requests to do this, and the
courtesy is appreciated.  I think it's now up to the WG to decide
what FCIP discovery/configuration mechanisms to REQUIRE
and/or RECOMMEND in the FCIP draft.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------