RE: iSCSI Discovery and SendTargets

["CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>]

Jim,

Thanks for the clarification.  This seems like a reasonable optimization,
but not something that one couldn't live without in practice.  If not, it
doesn't appear to be much of an extension to the existing mechanism anyway.
Perhaps if a 'named' target is used in the command it only returns info
about that target...

Paul

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, June 05, 2001 12:12 PM
> To: CONGDON,PAUL (HP-Roseville,ex1)
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI Discovery and SendTargets
> 
> 
> 
> Paul,
> 
> Just a note of clarification. The ReportPortalGroups is 
> intended to get the
> aggregation tags information for the specific target one is 
> logged into.
> It's nothing more than that.  You can think of SendTargets as the
> equivalent of "Send all Target Names with ReportPortalGroups 
> for each".
> Or you can think of ReportPortalGroups as "SendTargets filtered by a
> specific iSCSI target name".
> 
> It allows an iSCSI initiator to have only a name and ONE 
> address for an
> iSCSI target, do login and THEN figure out about the 
> aggregation tags (for
> multiple connection coordination), without having to do a 
> SendTargets and
> possibly get back a lot of other target information that it 
> (the initiator)
> doesn't care about.
> 
> Jim Hafner
> 
> 
> "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>@ece.cmu.edu on
> 06-05-2001 11:57:32 AM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> 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     +
> +--------------------------+----------------------------+
> 
> 
> 
> 
>