Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning

From: [email-masked]
Date: Wed, 6 Jun 2001 00:35:45 +0300

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)" <[email-masked]> on 05-06-2001
21:57:32

Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>

To:   "'Mark Bakke'" <[email-masked]>, IPS <[email-masked]>
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: [email-masked] +
+ 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     +
+--------------------------+----------------------------+

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 5 Jun 2001 20:31:21 -0400

Julo,

> -check and invalidate  them as needed
 
A target device with a network interface already has to have a "management
infrastructure", regardless of whether or not SendTargets is part of the
iSCSI protocol.  The IP-ness of the device requires that the user be able to
configure IP addresses, masks, gateway's, DNS servers (possibly) and there's
also the configuration of a target name, should a user want to change the
target's default name.

-Marj

---

From: [email-masked]
Date: Wed, 6 Jun 2001 05:21:28 +0300

---------------------- Forwarded by Julian Satran/Haifa/IBM on 06-06-2001
05:21 ---------------------------

Julian Satran
06-06-2001 00:35

To:   [email-masked]
cc:
From: Julian Satran/Haifa/IBM@IBMIL
Subject:  RE: iSCSI Discovery and SendTargets or Expediency vs. Planning
      (Document link: Julian Satran - Mail)

Paul,

etc.

Julo

Mark and NDT team,

Paul

---

From: [email-masked]
Date: Wed, 6 Jun 2001 05:26:53 +0300

Marjorie,

This is exactly my point. SendTargets has to be part of the management
infrastructure and not the iSCSI operational structure.  It can live and
thrive there.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]> on
06-06-2001 03:31:21

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI Discovery and SendTargets or Expediency vs. Planning

Julo,

A target device with a network interface already has to have a "management
infrastructure", regardless of whether or not SendTargets is part of the
iSCSI protocol.  The IP-ness of the device requires that the user be able
to
configure IP addresses, masks, gateway's, DNS servers (possibly) and
there's
also the configuration of a target name, should a user want to change the
target's default name.

-Marj

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 6 Jun 2001 13:01:06 -0400

I'm sensing sarcasm here...  If so, lets take the jokes offline.  People
have better things to do.  If not, then consider my responses below...
Nothing is ever "easy to do" as you well know.

> - solution 1 is good because it is expedient (easy to do!)

I don't believe that was the crux of my message.  While option 1 is
expedient, it more importantly preserves the utility of the SendTargets
functionality within the current spec.  As I described, most of what you
need to support SendTargets will have to be implemented for general iSCSI
login, authentication and command text processing.  It will be easy for
customers to make good use of this feature in both small and large
environments.

> expedient in their own time!)

We should consider future extensions to a point, but we are all looking
forward to a initial stable version of this spec, and we should make sure we
are covering the most common and important cases.  Of course this is a
judgement call.

> -commonality with other discovery protocols has no appeal (you do net

Certainly we should not re-invent the wheel, but there is a fine line
between using a plethora of protocols and associated management to cover a
space and making a small augmentation to the base protocol to fill a basic
need.  My opinion is that SendTargets falls on the side of the line to
include in the iSCSI spec.

> -check and invalidate  them as needed

Very true, but there is great flexibility in how this is done without
changing the existing specification or creating a new one.  This may be done
on the targets themselves, on master targets, independent management servers
or no-where at all.

> And how about certificates, ACLs etc (we could accommodate 

Now I'm sure I'm hearing sarcasm...  This is device management.  While we
are at it, why not consider adding a command to set the baud-rate on the
target serial port...

Paul

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 6 Jun 2001 12:44:10 -0700

*My point* = the fact that configuration information needs to be managed
does not dictate the way information is exchanged.  We are already
exchanging some "configuration information" in the text commands so that the
iSCSI endpoints may communicate.  Are you saying we must remove all text
commands, since they are also "things that are part of the managed data"?
There have been extensions to the text commands - are we also tempted to add
"configure" text command options for them?  We have to exercise judgement on
all issues, we all agree.

-Marj
 
> > I would like to point out that the SendTargets should not 
> be considered
> as
> > a standalone thing.