SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Wrapping up SendTargets



    
    Josh,
    
    There is a fundamental difference of purpose behind SLPs and iSNS's.  The
    things you list below as missing from SLP are *not* discovery functions but
    go well beyond that into more complex management.
    
    The purpose of the Naming and Discovery Team's effort is to define
    discovery: in short how does an initiator "walk the bus".  We are not
    charged with full complex management issues.  When scoped in this way, SLP
    seems perfectly suitable for discovery.
    
    I have more specific comments on your points below, tagged with
    <JLH>...</JLH>.
    
    As for the general question of SendTargets, here's my opinion:
    
    1) I see no problem with SendTargets in the near term, it can be made
    obsolete in rev2 if that's the concensus at that time.
    
    2) We should move toward putting that function within SLP in the mid-term.
    
    3) There are open questions about how to deal with potentially long
    responses from SendTargets.  This needs careful thought; all current
    proposals have problems or have been incompletely specified.
    
    4) The ReportPortalGroups function is critical and needs to stay (for
    clarity, ReportPortalGroups is the Text command that requests, in the
    context of an established login to a full functioning iSCSI Target w/SCSI
    target, the list of ipaddress/tcpports+tags that express the sessioning
    coordination functions of the target).  Whether the syntax of this is
    "SendTargets <iscsiname>" or just "ReportPortalGroups" is immaterial
    (unless the expectation is that SendTargets goes obsolete in which case,
    the syntax should be stable, so perhaps a specific key for it would be
    best).
    
    Jim Hafner
    
    
    Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 06/08/2001 06:26:01
    PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   "'Mark Bakke'" <mbakke@cisco.com>, IPS <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI: Wrapping up SendTargets
    
    
    
    Mark,
    
    > For adding discovery functionality beyond basic reporting
    > of available targets and addresses, I have seen 5
    > (again, including myself) in favor of using SLP for
    > future discovery, one in favor of using iSNS for future
    > discovery, two in favor of either SLP or iSNS, and
    > three with no comment.
    >
    > I realize that this doesn't constitute calling consensus,
    > and I'm not the person to do it, but I wanted to point out
    > where most people who have responded seem to be headed,
    > so that others who wish to be heard are motivated to
    > comment.
    
    Am I missing something here?  I had thought the previous
    discussions on this thread were regarding use of Sendtargets,
    not a referendum on SLP or iSNS.
    
    I am still waiting for a technical response to my previous
    messages over the last two months regarding iSNS and SLP.
    SLP lacks essential capabilities that iSNS provides, and
    no one has been able to explain how they will provide them
    with SLP or any other protocol.  How can you possibly say
    we are headed in the direction of SLP when its technical
    issues as far as addressing storage discovery issues have
    not been resolved?
    
    > I see a mild consensus toward SLP as a good direction for
    > moving forward with discovery beyond simple target reporting.
    > The SLP folks themselves intended for hosts to be able to
    > behave in the Unicast manner we are trying, and are interested
    > in updating the SLP API to handle this.  However, I think that
    > it would be best to use SendTargets for now, while we both
    > make sure that the right SLP API is developed, and that we
    > can solve the problem of authentication schemes.
    >
    
    Before you or anyone calls consensus, I would like to see
    how SLP can solve the following issues:
    
    1)  Management of Discovery Domains.  You don't want
    incompatible file systems discovering each other, or
    very bad things will happen.  Say 'goodbye' to the Unix
    file system who's host is discovered by SLP....
    
    <JLH>
    Discovery does not constitute a major exposure; discovery only lets an
    initiator know that something exists.  The full security context of login
    is still there as the major barrior to authentication and authorization.
    So the integrity problem you speak of isn't there (in iSCSI, though it is
    there in FCP).
    </JLH>
    
    
    2)  Transfer of X.509 digital certificates.  SLP cannot
    easily transfer binary entities.  This affects the iSCSI
    target device's ability to enforce its access control list.
    
    <JLH>
    How so? Again, the SLP is only used to find the existence of the device.
    The iSCSI login does the hard part of enforcement and that happens on a
    completely different connection with a completely different protocol from
    SLP discovery.  SLP isn't going to be used for the target to get its access
    control list (as you want iSNS to do).  Configuration of those lists is NOT
    a discovery function and can be handled by direct management functions on
    the target.  This may not be the cleanest way, but it is functional (it's
    what people are doing today in more contexts that just iSCSI).
    </JLH>
    
    
    3)  Monitoring of available devices.  SLP relies upon
    service agents re-registering periodically, in order to keep
    the freshness of its database entries.  But this leads to a
    dilemma: if SA's re-register too often, the DA will be
    overwhelmed.  And if they register not often enough, then
    you will have stale device entries.  The fact is, SLP was
    not designed to be a real-time discovery protocol. But in
    storage networks, real-time information is crucial, as even
    slightly out-of-date information can lead to unnecessary
    logins and other events that will seriously degrade the
    performance of the storage network.
    
    <JLH>
    I don't see this as a major problem either.  Discovery and login should
    happen relatively infrequently in a storage network (e.g., at boot time or
    "rescan" time).  Slightly stale information is probably not a major problem
    and will almost certainly only affect a limited number of systems.
    </JLH>
    
    4)  State Change Notifications.  This is important to
    support failover and redundancy capabilities, and to
    ensure that initiators can persistently maintain their
    sessions with targets in the event of network topology
    changes.
    
    
    >
    >   Now    - Keep SendTargets, document it in the iSCSI spec, and
    >            declare its limitation to just what is needed to
    >            connect to a target (name, address, aggregation).
    >
    >            Define ReportPortalGroups functionality as a subset
    >            of SendTargets.
    
    I understand you'll be out of contact for the next 1.5 weeks,
    and so you must be in a rush, but I must ask that you give us a
    at least a few days or so to digest the 10+ messages on this
    subject. I personally have been in-and-out of the office for the
    past couple days and haven't been able to respond till now.
    
    Once again, I support John's proposal to move Sendtargets to
    the annex.  I don't think Sendtargets should be in the main
    document.
    
    Furthermore, it would be helpful if you clarify whether your
    statements are representing the iSCSI NDT or only of your
    personal views.  I do not believe your statements regarding
    the SLP approach for iSCSI are consistent with what was
    agreed to in the NDT.  I believe the consensus was that both
    iSNS and SLP are to be considered for discovery.
    
    >   Future - Pursue SLP as the "standard discovery", allowing for
    >            other solutions such as iSNS as appropriate.
    
    As an NDT member, I cannot support a decision on making any
    protocol the "standard" without fully addressing the above
    technical issues. The devil is in the details, and only after
    exploring such issues will we be able to avoid future pitfalls
    that may threaten the timely adoption of iSCSI.
    
    Josh
    
    > -----Original Message-----
    > From: Mark Bakke [mailto:mbakke@cisco.com]
    > Sent: Friday, June 08, 2001 1:31 PM
    > To: IPS
    > Subject: iSCSI: Wrapping up SendTargets
    >
    >
    >
    > Dear Discovery Enthusiasts-
    >
    > The SendTargets threads are winding down, so I would like
    > to see if we have a rough consensus on a few things.
    >
    >
    > I've read through all of the threads on whether to
    > keep SendTargets in iSCSI, and I believe there is
    > a rough concensus that we should keep it in, carefully
    > limit its growth, and recommend that functionality
    > beyond the basic reporting of the targets and addresses
    > available be implemented using standard discovery
    > protocols instead.  On looking through responses from
    > Josh, Steph, Larry, Paul, Julian, Mallikarjun, John,
    > Kaladhar, Jim, and Marjorie, I have seen 7 (I include
    > myself in this count) in favor of keeping SendTargets
    > but limiting its growth, one in favor of dropping
    > SendTargets, and three with no comment on SendTargets.
    >
    > For adding discovery functionality beyond basic reporting
    > of available targets and addresses, I have seen 5
    > (again, including myself) in favor of using SLP for
    > future discovery, one in favor of using iSNS for future
    > discovery, two in favor of either SLP or iSNS, and
    > three with no comment.
    >
    > I realize that this doesn't constitute calling consensus,
    > and I'm not the person to do it, but I wanted to point out
    > where most people who have responded seem to be headed,
    > so that others who wish to be heard are motivated to
    > comment.
    >
    >
    > Anyway, that said, I would like to see SendTargets stay
    > in the draft, mainly for the same reasons that several
    > others already stated:
    >
    >   SendTargets shares the same authentication as iSCSI.
    >
    >   SendTargets provides a simple, low-risk path to building
    >   interoperable, minimal-configuration iSCSI implementations.
    >
    >   SendTargets builds on the existing iSCSI login and text
    >   commands, and will be the smallest-footprint and -effort
    >   way to implement this basic functionality.
    >
    > The first reason given above is the most important.
    >
    > I believe that we should limit extensions to it as much as
    > possible, for instance, we should not attempt to return
    > certificates and other information.  Implementations that
    > wish to do fancier things like these would implement one
    > of the other discovery mechanisms.  We could go as far
    > as atrophying SendTargets later, but I think that John is
    > right, that it would be a decision to be made later (iSCSIv2).
    >
    > That said, I do agree that Julian is correct from a philosophical
    > point of view; discovery really belongs outside the protocol.
    > This is a direction we need to pursue.  I absolutely agree with
    > Julian that we have to be careful not to let something like
    > SendTargets turn into a management protocol. It would be "easy
    > to do" :-).
    >
    > I see a mild consensus toward SLP as a good direction for
    > moving forward with discovery beyond simple target reporting.
    > The SLP folks themselves intended for hosts to be able to
    > behave in the Unicast manner we are trying, and are interested
    > in updating the SLP API to handle this.  However, I think that
    > it would be best to use SendTargets for now, while we both
    > make sure that the right SLP API is developed, and that we
    > can solve the problem of authentication schemes.
    >
    >
    > On ReportPortalGroups
    >
    > I did not hear anyone say we didn't need this functionality; most
    > seemed to say the we either "at least" need ReportPortalGroups
    > if we don't have SendTargets, or that SendTargets was assumed,
    > and ReportPortalGroups is a subset.
    >
    > I agree that this is necessary functionality, but that if we
    > can assume that we still have SendTargets, ReportPortalGroups
    > is really a subset.  Paul mentioned just using:
    >
    >   SendTargets <iscsi-target-name>
    >
    > would be the same as ReportPortalGroups.  This might help
    > avoid the feature creep that some of the responders feared.
    >
    > Anyway, either way of doing ReportPortalGroups (making it its
    > own command or making it part of SendTargets) is fine with me.
    > I think that the consensus was that as long as we have SendTargets,
    > we should use it for the ReportPortalGroups functionality.
    >
    >
    > On the Growth of SendTargets
    >
    > A few people mentioned concern about TargetAlias and digital
    > certificates.  TargetAlias is returned by the target upon login
    > anyway, so I could live with removing it from SendTargets, and
    > letting the higher-level discovery/management mechanisms deal
    > with it.  I think that the same goes for certificates.  As we
    > figure out how our customers really want to do security for iSCSI,
    > we may have other mechanisms in place for handling these.
    >
    > This should help keep SendTargets from growing.  Stating that
    > it is limited to name, address, and aggregation information (just
    > what is required to connect) should keep it right where it is,
    > and the future discovery mechanisms can take over from there.
    >
    > So here's what I think we have:
    >
    >   Now    - Keep SendTargets, document it in the iSCSI spec, and
    >            declare its limitation to just what is needed to
    >            connect to a target (name, address, aggregation).
    >
    >            Define ReportPortalGroups functionality as a subset
    >            of SendTargets.
    >
    >   Future - Pursue SLP as the "standard discovery", allowing for
    >            other solutions such as iSNS as appropriate.
    >
    > Do we have rough consensus on either of the above, at least
    > on the "Now" part?
    >
    > Once we have consensus on that, we can continue the threads
    > on aggregation tags, which targets should provide SendTargets,
    > and whether or not we need iterators.
    >
    > Anyway, I have to apologize in advance; I will be out of
    > the office until the 18th, so I am sort of throwing this out
    > on the list and running away.
    >
    >
    > Regards,
    >
    > --
    > Mark A. Bakke
    > Cisco Systems
    > mbakke@cisco.com
    > 763.398.1054
    >
    
    
    
    


Home

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