RE: iSCSI Discovery and SendTargets or Expediency vs. Planning

[julian_satran@il.ibm.com]

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     +
+--------------------------+----------------------------+