SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: FCIP - Discovery should be Manual/SLP


    • To: "Dave Peterson" <dap@cisco.com>, "Anil Rijhsinghani" <anil.rijhsinghani@mcdata.com>, <ENDL_TX@computer.org>, "IPS Reflector" <ips@ece.cmu.edu>
    • Subject: RE: FCIP - Discovery should be Manual/SLP
    • From: "Elizabeth Rodriguez" <egrodriguez@lucent.com>
    • Date: Thu, 24 May 2001 13:09:09 -0400
    • Content-Class: urn:content-classes:message
    • Content-Transfer-Encoding: 8bit
    • Content-Type: text/plain;charset="iso-8859-1"
    • Disposition-Notification-To: "Elizabeth Rodriguez" <Elizabeth.Rodriguez@nc8220exchange.ral.lucent.com>
    • Sender: owner-ips@ece.cmu.edu
    • Thread-Index: AcDkccIy7r3flIhRRlaLf1s6Qc8mmAAAc5YA
    • Thread-Topic: FCIP - Discovery should be Manual/SLP

    (Chair hat off)
    
    Anil,
    
    Correct me here if I am wrong, but I thought no mandatory to implement
    discovery mechanism was going to be prescribed for FCIP. If a dynamic
    discovery mechanism was desired, then SLPv2 would be the method to
    implement.
    
    Elizabeth
    
    -----Original Message-----
    From: Dave Peterson [mailto:dap@cisco.com]
    Sent: Thursday, May 24, 2001 10:53 AM
    To: Anil Rijhsinghani; ENDL_TX@computer.org; IPS Reflector
    Subject: RE: FCIP - Discovery should be Manual/SLP
    
    
    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
    
    


Home

Last updated: Tue Sep 04 01:04:37 2001
6315 messages in chronological order