Subject: SLP, iSNS, and iSCSI

From: [email-masked]
Date: Wed, 23 May 2001 20:06:18 -0400

I previously noted a couple of thing about SLP that
appear not to have been part of prior discussions:

[A] SLP scopes are allowed to overlap in a fashion
similar to Fibre Channel zones -- Service, User,
and Directory Agents can each be in multiple scopes.

[B] RFC 2610 specifies DHCP options for configuring
SLP Directory Agent locations and SLP scopes for both
User and Service Agents.  This would allow DHCP to be
used for centralized administration of an SLP
infrastructure, and works even when DHCP is not used
for IP address assignment.

Going back to Josh Tseng's analysis of SLP and
iSNS for iSCSI, Josh covered the following topics:

(1) State Change Notification
(2) Multicast
(3) Zoning and Discovery Domains
(4) Heartbeat
(5) Non-string attributes
(6) Security

This is a note about the impact that [A] and [B]
have on these 6 items, plus some related comments
based on the SLP notification mechanism in RFC 3082

-- (1) State Change Notification

[A] and [B] don't seem to affect this area.  RFC 3082
provides some level of support (but see next item).
From a process standpoint, RFC 3082 is experimental,
and hence can't be required by a standards-track
document.  Unlike FCIP, iSCSI is client-server and
hence has a use/need for some way of informing clients
(Initiators) that a new server (Target) has appeared.

-- (2) Multicast

SLP requires both service and directory agents to listen for
multicast requests, but can be configured in a fashion where
they're never used.  The RFC 3082 notification mechanism
*requires* multicast, which is likely to be an issue in
larger networks and some VPN situations.

-- (3) Zoning and Discovery Domains

Both [A] and [B] matter here, and the appropriate
comparison is probably SLP + DHCP vs. iSNS.  For
SLP + DHCP, it looks like SLP scope is usable in the
same fashion as an iSNS Zone/Discovery Domain, modulo
issues with State Change Notification [(1) above].

-- (4) Heartbeat

Neither [A], [B] nor RFC 3082 affect this area, but
it doesn't seem to be a major issue -- the concern
is how long an SLP Directory Agent may cache information
for and hence how often an SLP Service
Agent has to refresh its registration(s).  A few minutes
might be a good answer here since that's the default time
for SLP to keep idle TCP connections open.

-- (5) Non-string based attributes

[A], [B], and RFC 3082 appear not to have any effect here.
Whether we need to distribute things like X.509 certs through
the SNS appears to be an open issue.

-- (6) Security

The fact that multiple scopes can be used and that the
DEFAULT SLP scope can be removed from SLP directory agents
(RFC 2608, Section 12.4) appears to remove the argument
that the SLP Directory Agent is a central point of trust.
DHCP doesn't need to replace it as a central point, as
DHCP is readily partitionable along network topology
boundaries.

An important note about this area is that iSCSI access
control departs from the model(s) used in Fibre Channel
in an important aspect.  In Fibre Channel, end systems
trust the Fabric to handle certain aspects of access
control - both soft and hard zoning are primarily
implemented in switches (and soft zoning also trusts
HBAs to not do port scans).  For iSCSI, Targets are going
to find themselves more involved in access control and
authentication of Initiators.  There will be cases such
as strict VLAN configuration along with no layer 3 gateway
out of the VLAN reproduce Fibre Channel-like configurations,
but iSCSI will need to operate in more general networks.

This is all for discussion.  An initial take on this
is that State Change Notification (1) is still an area
in which SLP appears to fall short of iSNS, especially
if RFC 3082 notification is ruled out of bounds due to
its dependence on multicast.  OTOH, DHCP appears to
be a viable route to central administration of SLP.

Comments?,
--David

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

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 23 May 2001 19:30:31 -0700

David,

> for IP address assignment.

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.

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

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.

Josh

---

From: [email-masked]
Date: Thu, 24 May 2001 16:28:36 -0400

Josh,

> doesn't even have an IP address, not to mention an FQDN

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

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

> 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

---

From: Joshua Tseng <[email-masked]>
Date: Thu, 24 May 2001 15:05:25 -0700

David,

> 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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 1:29 PM
> To: [email-masked]; [email-masked]
> Subject: RE: SLP, iSNS, and iSCSI
> 
> 
> Josh,
>