SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Discovery and SendTargets or Expediency vs. Planning



    
    
    Paul,
    
    Just to be sure that I understood well your line of thought:
    
    - solution 1 is good because it is expedient (easy to do!)
    -future extensions should not be considered at this time (they will become
    expedient in their own time!)
    -commonality with other discovery protocols has no appeal (you do net
    mention it)
    
    I would like to point out that the SendTargets should not be considered as
    a standalone thing.
    It will (has to) be supported by a management infrastructure that:
    
    - has to install the names
    -check and invalidate  them as needed
    
    etc.
    
    Should we start also adding ReceiveTargets to install the names in the
    targets (it very easy to add!).
    And how about certificates, ACLs etc (we could accommodate those too1).
    
    Julo
    
    
    
    
    "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com> on 05-06-2001
    21:57:32
    
    Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>
    
    To:   "'Mark Bakke'" <mbakke@cisco.com>, IPS <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI Discovery and SendTargets
    
    
    
    
    
    Mark and NDT team,
    
    Nice write-up of your discussions.  In summary I would like to strongly
    support the position of option 1 in your memo, which is keeping SendTargets
    as-is with the few minor modifications to support aggregation tags, but not
    much else.  We do need to contain the scope of SendTargets, but removing it
    from the spec would be a tremendous loss of a very simply yet powerful
    feature.  My supporting comments are as follows:
    
    1. Keeping SendTargets basically as-is, but with the addition of
    aggregation
    tags is a very small increment over what must already be implemented for
    general iSCSI login, authentication and text processing.  It is basically
    just another text command that has very wide spread utility.
    
    2. The fact that a discovery session, where SendTargets can be performed,
    uses the exact same authentication and login mechanisms is a fundamental
    benefit of the scheme.  Alternatives will require their own (albeit
    similar)
    implementations for authentication.  Deploying, configuring and maintaining
    AAA infrastructure has always been a stumbling block for customers and
    complicating this with additional protocols and clients will not help
    matters.
    
    3. The complication of an iterator can be avoided if we restrict the usage
    of SendTargets to a session on a well-known target or clearly document the
    potential issues of blocking a connection in an implementation.  However, I
    would support the definition of an iterator if there is consensus.  This is
    not a show-stopper.
    
    4. Splitting SendTargets into multiple commands (ReportTargets and
    ReportPortalGroups) seems unnecessary and not relevant.  I have not heard
    the entire discussion surrounding ReportPortalGroups, but it would seem
    that
    this information would be better reported via the MIB or at least should be
    made available via the MIB.  Even if there is a need for such a command
    then
    it appears to be an entirely separate issue.
    
    5. Enhancing SendTarget responses to include additional information
    regarding certificates or boot related information appears to be in the
    category of 'creeping elegance' and does not to need to be considered at
    this time.  Facilities will be in place to establish the session needed to
    perform SendTargets anyway, and returning additional information that
    allows
    one to avoid using these facilities is purely an optimization.
    
    6. An example of SendTarget's power and simplicity (as-is) is the ability
    to
    use it to create a SendTargets tree as you've described.  There is really
    nothing that "needs" to be changed from the current scheme to support this
    behavior.  This is a perfect example of how the very same mechanism can be
    used to 'scale' in environments from very small plug-and-play workgroups to
    a large centrally administered, highly secured, enterprises.
    
    So, from an expediency and philosophical perspective I believe we should
    implement SendTargets now and contain the number of proposed changes to
    keep
    it as simply as possible.  We should NOT move this to another document,
    since it is really just another text command, but a very powerful one at
    that.
    
    Paul
    
    +--------------------------+----------------------------+
    + Paul Congdon             + Email: paul_congdon@hp.com +
    + Hewlett Packard Company  + Mail Stop:  5662           +
    + HP ProCurve Networking   + Phone:  (916) 785-5753     +
    + 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
    + Roseville, CA   95747    + Mobile: (916) 765-4056     +
    +--------------------------+----------------------------+
    
    
    
    
    
    


Home

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