RE: Proposal to use SLPv2 for FCIP device discovery

[Joshua Tseng <jtseng@NishanSystems.com>]

Dave,

See below:

> 
> As requested here is the proposal I presented at Mondays' 
> FCIP meeting:
> 
> FCIP Draft Proposal
> For Clause 4.2, item 3.
> 
> Each FCIP device may be statically or dynamically configured 
> with a list of
> IP addresses and port numbers corresponding to all the 
> participating FCIP
> devices. If dynamic discovery of participating FCIP devices 
> is supported
> this function shall be performed using the Service Location Protocol
> (SLPv2). For additional FCIP device management capability, 
> the iSNS Internet
> Storage Naming Service may be implemented. It is outside the 
> scope of this
> specification to describe any static configuration method for 
> participating
> FCIP device discovery. Refer to clause XXX for a detailed 
> description of
> dynamic discovery of participating FCIP device using SLPv2.

I disagree that use of either SLP or iSNS should be mandatory.
In fact, if iSNS is used, then SLP SHOULD NOT be used for FCIP
device discovery (although it MAY be used to discover the iSNS
server).  The reason for this is that the iSNS assumes it has
control of the discovery and management process.  Using SLP
simultaneously undermines the authority of the iSNS to control
discovery domains.

> 
> Notes:
> 1. DHCP:
> 	a. Allows an entity to discovery information about 
> itself, not discover
> information about all other entities.
> 	b. Uses a broadcast mechanism that may not work via 
> routers without
> additional configuration. But, most current router 		
> implementations will
> support the forwarding of DHCP requests across routed subnets.
> 	c. May be used to find SLP Directory Agents and Scope 
> Lists allowing for a
> more scalable solution.

In addition, DHCP may be used to find the location of the iSNS server.

> 2. DNS Services are too limiting. This is the reason why SLP 
> was started.
> 3. LDAP is simply a database interface. SLP and iSNS may use LDAP as a
> back-end store.
> 4. SLP FCIP Device Type Specifics
> 	a. IP address(es)
> 	b. Port numbers(s)
> 	c. Scope
> 	d. Attributes
> 		i. Discovery domain (i.e. a group name or zone 
> name, don't want to use
> zone name in this context though)
> 		ii. need to start listing these (if we can 
> think of any more)
> 	e. Lifetime
> 
> Work In progress:
> 1.	Putting together a model for FCIP device discovery using SLPv2.
> 2.	Implementing a "default/suggested" SLPv2 template.
> 3.	Reviewing RFC 3082 - Notification and Subscription for 
> SLP for enhanced
> device notification.
> 
> Requirements							
> SLPv2	iSNS
> Discovery of FCIP targets					
> Y	Y
> Discovery of FCIP device IP address(es)			
> Y	Y
> Discovery of FCIP port number(s)				
> Y	Y
> Attribute support						
> 	Y	Y
> Semi-timely notification of devices coming and going	Y	Y
> Authentication						
> 	Y	Y(uses SLPv2 constructs)
> Minimal/no configuration					
> Y	Y(?)
> Provisioning							
> Y	Y
> Multicast support						
> 	Y	N
> Publicly available source					
> Y	N

iSNS will be available by the end of May.

> Standardized and mature					
> 	Y	N

I haven't seen SLP templates for FCIP.  Did I miss
them?  If so, could you send them to me?  Thanks.
Has an implementation of SLP been tested with
FCIP yet?  

> Lighweight implementation					
> Y	N

As will be shown, iSNS clients are about as lightweight as
you can get.

> 
> Non-Requirements
> Zoning							
> 	N	Y
> State Change Notification					
> N	Y
> Naming Services						
> 	N	Y

What criteria did you use to label these as non-requirements?

Thanks,
Josh
> 
> 
> David Peterson
> Lead Architect - Standards Development
> Cisco Systems - SRBU
> 6450 Wedgwood Road
> Maple Grove, MN 55311
> Office: 763-398-1007
> Cell: 612-802-3299
> Email: dap@cisco.com
>