RE: FCIP - Discovery should be Manual/SLP

["Dave Peterson" <dap@cisco.com>]

I am not opposed to performing static configuration using the FCIP MIB
and can provide appropriate wording but I think we should also allow the
capability of static configuration using other methods (e.g., command line
interface).

Dave

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Anil Rijhsinghani
> Sent: Thursday, May 24, 2001 10:17 AM
> To: 'ENDL_TX@computer.org'; IPS Reflector; 'dap@cisco.com'
> Subject: RE: FCIP - Discovery should be Manual/SLP
>
>
> Agree with the use of SLPv2 as the only mandatory discovery mechanism
> for FCIP, with naming/zoning not being requirements for FCIP.
>
> Note that static configuration (as opposed to dynamic discovery method)
> will be specified in the FCIP MIB, so I would replace the wording below
> "static config is outside the scope of this specification" to
> "static config is specified in the FCIP MIB document".
>
> Regards,
> Anil
>
> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Wednesday, May 16, 2001 3:25 PM
> To: IPS Reflector
> Subject: FCIP - Discovery should be Manual/SLP
>
>
> I support Dave's proposed text for FCIP Clause 4.2 item 3, with the
> exception that the sentence regarding iSNS needs to be removed.
> Looking at the features list, I cannot see any iSNS unique features
> that are meaningful to FCIP.
>
> Thanks.
>
> Ralph...
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Subject: Proposal to use SLPv2 for FCIP device discovery
> Date: Mon, 30 Apr 2001 17:07:08 -0500
> From: "Dave Peterson" <dap@cisco.com>
> To: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
>
>
> 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.
>
> 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.
> 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*
> Minimal/no configuration                                Y       Y(?)
> Provisioning                                            Y       Y
> Multicast support                                       Y       N
> Publicly available source                               Y       N
> Standardized and mature                                 Y       N
> Lighweight implementation                               Y       N
>
> Non-Requirements
> Zoning                                                  N       Y
> State Change Notification                               N       Y
> Naming Services                                         N       Y
>
> * uses SLPv2 constructs
>
>
> 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