RE: SLP, iSNS, and iSCSI

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

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

Thank you for your explanation, and I agree that it is
a WG issue now.

Regards,
Josh

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, May 24, 2001 1:29 PM
> To: jtseng@NishanSystems.com; ips@ece.cmu.edu
> Subject: RE: SLP, iSNS, and iSCSI
> 
> 
> 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
> ---------------------------------------------------
>