Subject: iSCSI: Wrapping up SendTargets

From: Mark Bakke <[email-masked]>
Date: Fri, 08 Jun 2001 15:31:16 -0500

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
[email-masked]
763.398.1054

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 8 Jun 2001 14:55:31 -0700

I agree with Mark's statements:
"  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).

  Future - Pursue SLP as the "standard discovery", allowing for
           other solutions such as iSNS as appropriate."

especially since most folks that bothered to respond did not like my
compromise of an Annex.

The only important point, from my standpoint is: if SendTargets goes away
for any reason, we still need the ReportPortalGroups function.  So if we
use the suggested syntax of "SendTargets <iscsi-target-name>" instead of
ReportPortalGroups, we need to find a way to protect the subset  function
that is "ReportPortalGroups", so it never goes away even if SendTargets
does.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

Mark Bakke <[email-masked]>@ece.cmu.edu on 06/08/2001 01:31:16 PM

Sent by:  [email-masked]

To:   IPS <[email-masked]>
cc:
Subject:  iSCSI: Wrapping up SendTargets

On ReportPortalGroups

Regards,

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 8 Jun 2001 18:26:01 -0700

Mark,

> so that others who wish to be heard are motivated to

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?

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

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.

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.

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.

>            Define ReportPortalGroups functionality as a subset

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.

>            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:[email-masked]]
> Sent: Friday, June 08, 2001 1:31 PM
> To: IPS

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 8 Jun 2001 22:15:08 -0700

Josha,
I failed to notice the exact meaning of the words that Mark used when he
said

"Future - Pursue SLP as the "standard discovery", allowing for
>            other solutions such as iSNS as appropriate."

I also believe that we agreed to have Both SLP and iSNS be considered for
discovery equally.

With iSNS being made Open Source, it seems to me that there is little
reason to not include it as a full participant, especially since it meets
the needs of the larger environments.  I also have not seen a reason why it
will not work in the medium environments, at least as well as SLP.

.
.
.
John L. Hufferd

Joshua Tseng <[email-masked]>@ece.cmu.edu on 06/08/2001 06:26:01
PM

To:   "'Mark Bakke'" <[email-masked]>, IPS <[email-masked]>
cc:
Subject:  RE: iSCSI: Wrapping up SendTargets

Mark,

Josh

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 11 Jun 2001 07:23:02 -0700

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

Mark,

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

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

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

Josh

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 11 Jun 2001 11:35:11 -0700

I support Mark's proposal and comments.  I'd like to add something to Jim's.

> obsolete in rev2 if that's the concensus at that time.

It doesn't seem like a good idea to consider obsoleting something
in the spec at this point.  If SendTargets stays-in and it gets
used (which I believe it will), it will need to continue to be
supported - unless you don't expect rev2 iSCSI targets to talk
with rev1 iSCSI initiators.

So for rev2, rather than simply considering obsolescence at this point,
we should consider adding additional functionality to SendTargets as
well.  Perhaps SLP is the right place for major new functionality,
but we shouldn't rule out updates to SendTargets, especially if
ReportPortalGroups must stay around.

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: [email-masked]
Date: Mon, 11 Jun 2001 20:24:45 -0400

> how SLP can solve the following issues:

Some of this was covered in:

http://ips.pdl.cs.cmu.edu/mail/msg04812.html

So, some short answers here ...

> file system who's host is discovered by SLP....

Management at the DHCP server of which SLP
scope(s) each system gets configured with.

> target device's ability to enforce its access control list.

I'm not sure that having yet another protocol
and server involved in security administration
is a "feature", let alone a "requirement".

These time periods are measured in minutes,
which doesn't sound like a scaling issue.
I'm sceptical that this is actually a problem
in practice, as something doing failover
(e.g., cluster software) will tend to have
its own mechanism to detect failure (e.g.,
what if the storage fails, but the controller
is still happily responding to iSNS polls?).

On this one, Josh is correct, especially about
discovery of new targets.  More and more OS's
can cope with this happening after boot, and
I believe HP-UX is among them ;-).  Being
able to hook up a new target and have it
automatically discovered by the corresponding
initiators could be very useful.

This is for further discussion.

Comments?,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 11 Jun 2001 16:41:04 -0700

Josh,

> file system who's host is discovered by SLP....

This function is the domain of an application value-add, and does not need
to be specified in the SLP protocol.  It is perfectly feasible for an
application that provides storage discovery services using SLP to filter the
information given to a particular initiator based on that initiator's
identity (just as a target would when responding to SendTargets).  The
'management of discovery domains' is a 'storage network management' related
value-add feature of an application, not something SLP must specify.

> target device's ability to enforce its access control list.

Again, this may be an application value-add, it's not a requirement for
storage discovery.  Security infrastructure is painful to administer.  Seems
to me as if a user would chose a generic security solution using something
like SCEP protocol, which would work for a variety of applications, not just
storage.  

> performance of the storage network.

I'm not sure I see the need for storage devices to "re-register" themselves
frequently since storage is not typically a highly dynamic configuration
environment.  You've made some statements about the real-time needs of
storage, but without specific examples I don't see how "real-time
monitoring" is a crucial requirement of a centralized storage resource
management service.

As for your concerns about SA's re-registering too often and overwhelming
the DA, this "push" model is viewed as having less problems than the "poll"
model where a centralized application requests status updates from multiple
devices (but there are tradeoffs with both models).  This is a classic
networked device monitoring problem, I don't think the group that developed
SLP would have ignored it in their protocol service design.
 
> sessions with targets in the event of network topology

This area of service really applies much more to a Fibre Channel domain than
an IP/iSCSI domain, due to differences in protocols.  Initiators shouldn't
need notification of target devices "going away", since the TCP connection
provides that information.  As for devices being added, there are a number
of ways to model this, that's another thread of discussion.  On first
thought, a model where an administrator triggers the update of initiators
when a target is added, rather than some automatic or polled environment
seems more desirable to me.  How many OS's can deal with storage suddenly
"appearing" after initial boot?  It seems that SLP could be used by an
application to provide this service if it's deemed necessary, it remains to
be specified "how".

> that may threaten the timely adoption of iSCSI.

I can't speak for Mark, but I think his intent may have been to express that
it remains to be fully specified "how" SLP can provide the same information
as "SendTargets" (we discussed this in the N&D team mtg).  Perhaps he didn't
mean to imply that it would be the only way to discover storage.

I would speculate that the group/IPS community as a whole has been focused
on minimal protocol connectivity, and mostly not had time/bandwidth to weigh
in on the greater "storage directory server" requirements.  Nishan has done
some good work on the iSNS application, the rest of us need to catch up on
considering which of it's features are "requirements of a generic storage
directory server" and which are value-add. 

Marjorie Krueger
Hewlett-Packard

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 11 Jun 2001 19:01:30 -0700

David,

> scope(s) each system gets configured with.

This is still manual configuration of SLP scopes.  In the
DHCP server, you would configure lists of MAC addresses
of DHCP clients with the DHCP option (containing the SLP
scope) to be assigned to that client.

So let's run through a summary of this process:

1)  Create list of iSCSI devices (identified by iSCSI name)
you want to include in a particular scope.

2)  Figure out the 6-byte MAC address for each of those devices.

3)  Enter each MAC address into a list in the DHCP configuration
file, along with a name for that scope to be sent as an option.

4)  Do the same thing for every other scope.

5)  Pray that you don't accidentally place the a MAC address
into the wrong list (e.g., your NT initiator into the list
containing your Unix file system hosts).

> is a "feature", let alone a "requirement".

As I mentioned in my message to Jim, the ability to configure
discovery domains and set up the security policies in a single
step, using one tool, would be useful IMO.  The alternative
is to configure your DHCP server (see above).  Then independently
configure your SRP for iSCSI.

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 11 Jun 2001 18:34:43 -0700

Hi Jim,

> go well beyond that into more complex management.

I believe most if not all of the issues I listed are fully or
partially discovery issues.  But regardless of whether they
are strictly "discovery" issues or not, they are issues that
need to be addressed somehow.  The question I have is do you
want separate tools to do discovery and management, or would
it be easier to have all discovery and management issues
addressed with one integrated protocol?  SLP would result in
a patchwork of multiple unrelated and uncoordinated tools and
protocols to do discovery, management, and monitoring of storage
devices.  I think this would be a setback for iSCSI.

iSNS is no more difficult to implement than SLP.  For the same
amount of effort to implement SLP, you could have iSNS and all
the management capabilities and real-time monitoring of devices.
So why would we "standardize" on SLP if additional protocols
will be needed to deliver essential management functions?

> seems perfectly suitable for discovery.

IMO, a critical part of the discovery problem is how you manage
the discovery capability, and whether you can manage the
scope of the discovery process.  SLP does not have this
capability; scopes must be managed manually.  This includes
the DHCP approach for managing SLP scopes--MAC addresses (not
iSCSI Names) must be manually mapped to a scope, and this mapping
is stored as a series of MAC address listings in the DHCP server.
(thanks, Glen Turner for pointing that out)

> So the integrity problem you speak of isn't there (in iSCSI, 

SLP has nothing to say about security and managing the context
of login.  So security and login configuration would have to
be manual or through some other mechanism. Since we are relying
on SRP authentication, the administrator is only an accidental
password mis-entry away from losing his Unix file system.  I
don't know about you, but this makes me nervous.  And it would
also take away the option of turning off the iSCSI authentication
mechanism (something they might want to do if they are in simple
network with few devices and no security concerns).

Security is meant to protect against deliberate attacks; it does
nothing to prevent against accidental mis-configurations.  The
threat here is accidental mixing of NT and Unix file systems,
and we should not be relying on the login process to protect
against this.

This goes without mentioning the wasted logins that will
take place even if the administrator is fortunate enough to
avoid mistakes in setting up his security and access control
policies.
> what people are doing today in more contexts that just iSCSI).

The ability to transfer X.509 certificates would be a
nice-to-have capability that I would hope the "standard" 
discovery protocol would be able to do.  No, it's not
absolutely essential to set up the security context, but
public key-based authentication would significantly cut down
the amount of configuration needed to set up the security.
iSNS does this by allowing the security setup to piggyback
on the discovery setup.

Josh

---

From: "Jim Hafner" <[email-masked]>
Date: Tue, 12 Jun 2001 16:56:10 -0700

Folks,

I think this thread is wandering off the field.

The question is the issue of SendTargets.  Let's remind ourselves of the
original purpose of this proposed protocol: namely, it's designed for a
storage box that contains one or more iSCSI target devices to report about
ITSELF, about what's in it!  This includes both a list of the iSCSI targets
it has PLUS the session coordination (via tags) of the various
IPaddress/tcpport combos it supports.

In other words, it's job is to report about itself!  The use of (unicast)
SLP as an alternative to SendTargets was focused exactly on the same
question: I ask a single box to tell me about itself.   This function lies
between the two extremes of (a) static configuration of initiators and (b)
centralized management via iSNS style services.

Somehow, someway, we need to define a protocol for a box to "tell us about
itself" in the absense of the centralized management infrastructure.  That
seems critical to me.  Even if I want to do static configuration, the guy
doing the configuration needs a way to get at the guts of each new box
he/she rolls into the environment.

The choices are, it seems, that *every* box would need to support at least
one of:
a) SendTargets
b) modified SLP
c) iSNS

What's the consensus on the protocol we aim for to solve this middle ground
discovery problem?
Jim Hafner

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 12 Jun 2001 19:01:21 -0700

Marjorie,
> value-add feature of an application, not something SLP must specify.

If this function doesn't need to be specified, then how do you 
intend to get mixed-vendor environments to deliver this
functionality?  One vendor supplies the target, a different
vendor supplies the initiator, and each vendor decides to
implement their own approach for configuring scopes or
discovery domains.  

Without a standard approach that delivers a full, comprehensive
set of capabilities (management, monitoring, discovery, etc...), 
each vendor will implement their own proprietary approach to
deliver incremental capabilities required to support their
individual iSCSI implementation.  There will not be seamless
interoperability, which would be a setback for iSCSI.  What
we will end up with is the "Tower of Babel".

I don't really care if you call iSNS an "application" or a
"protocol".  The point is, in the interest of interoperability,
we are proposing iSNS as a standard, comprehensive approach.
The operational model has been tested and proven, and it gives
you every capability SLP promises, and far more.  And we have
made the source code available to everyone.

Now why anyone would want to ignore all this and write their
own proprietary application to fill in feature gaps of SLP,
...well that's their own business...

> like SCEP protocol, which would work for a variety of 

iSNS is not a certificate server; it only provides for distribution
of X.509 public key certificates.  Strictly speaking, it is not
"security infrastructure" any more than an excel spreadsheet is.
But iSNS is a useful tool which can be used to store your
security policy, and much easier to use than storing your ACL's
and certificates on excel spreadsheets.

SCEP performs a different role than iSNS.  Indeed, iSNS could
be deployed alongside the SCEP server to distribute certificates
for storage devices.

> monitoring" is a crucial requirement of a centralized storage resource

See below.

> provides that information.  As for devices being added, there 

TCP can take minutes to time out.  The polling iSNS does gives
iSCSI another tool to detect when a device or port has been
disconnected.  Sure, as David pointed out it's not failsafe, since
the iSNS client could still be running fine despite a failed storage
controller.  But it's another tool to detect a failed or
disconnected device.

Otherwise, the alternative is to wait for TCP to time out (several
minutes).  The iSCSI initiator may decide to initiate another SLP query
to see if that device is somewhere on the network.  If the database
is not real-time and up-to-date, this could lead to further delays
before the final action to either abort the session or move it to
different TCP connections using alternate target interfaces.

This is not a major point, but I always thought having real-time
data is better than stale data.  I hope you agree.

> are a number
> some good work on the iSNS application, the rest of us need 

Thanks!
Josh

> to catch up on

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 12 Jun 2001 20:50:52 PDT

>
>iSCSI Team,
>I think that Jim has said it well.  I had a proposal about an Annex, for
>the SendTargets, but whether we do that or not, I am getting the feeling
>that most folks think, at least for this version of the protocol that we
>keep SendTargets, and the subset that can be used as a Report Portal
>Groups.  Even Mark, even though he thought he could Hack the SLP Source
>code to do a similar thing, thought that it was best to keep SendTargets.
>
>I would like to propose that we Close on Keeping the SendTargets command,
>and the subset that is either Report Portal Groups or SendTargets <iSCSI
>Target Name> (which returns only the information for that target only).
>
>Now as to where we put the command.  I suggested an Annex, but can clearly
>live with it in the Main document.  I seemed to get very little support for
>the idea of the Annex, and since I think that the functions of Report
>Portal Groups, must be part of the base,  I would like to suggest that we
>either
>1) Place the SendTargets in the Annex, and put a Report Portal Groups in
>the main document, or
>2) Keep the Send Targets in the Main Document and add the argument of
><iSCSI Target Name>
>
>Please state your positions

My support is for option 2 for the reasons that I alrady listed 
in my previous posting.  
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

>Jim Hafner/Almaden/IBM@[email-masked] on 06/12/2001 04:56:10 PM
>
>To:   [email-masked]

---

From: "Sperry, Todd" <[email-masked]>
Date: Wed, 13 Jun 2001 10:33:44 -0700

John & Company,

I think that the arguments for (and against) leaving SendTargets
in the main draft, as an annex, or outside of the iSCSI draft
altogether all have some merit and that's why this is a difficult
decision.  I tend to agree with Marjorie's assesment of the 
situation...

>IMO, it's a judgement call where you draw the line between architectural
>purity and practical functional encapsulation.  My current feeling is that
a
>limited SendTargets function adds a small amount of implementation burden
>and a large amount of functional value to product solutions.

The work towards implementing the SendTargets targets functionality
outside of iSCSI should likely continue.  At this point, we have Mark's
verification of workability, but still we have questions about
security/authentication, changes to drafts, etc.

Finally, the ReportPortalGroups is good idea, and it seems to me
more closely tied to the session nature of the iSCSI protocol.
However, because I'm leaning towards leaving SendTargets in the
main draft, I would recommend the SendTargets <iSCSI name> syntax.

So, I'm arguing for John's suggestion of #2.

Thanks,
Todd.

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 6:09 PM
To: [email-masked]
Subject: RE: iSCSI: Wrapping up SendTargets

iSCSI Team,

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Folks,

---

From: [email-masked]
Date: Wed, 20 Jun 2001 20:21:53 -0400

Since this seems to need a consensus call, I believe the
WG consensus on SendTargets for iSCSI is:

- Retain the functionality, document it in the main
	portion of the specification.
- SendTargets will not return Aliases or Certificates.
	This is part of limiting its functionality to
	basic description of the iSCSI device to which
	it is attached.
- Add an <iSCSI Target Name> argument to Send Targets
	to enable it to perform what has previously been
	called Report Portal Groups.  When the target name
	is present (even the canonical "iscsi" target),
	the result is to return portal information.

Reviewing the mail thread since Mark's initial message
with the above subject line:
- Doug Otis's objections appear to be to iSNS and not
	to the above proposed SendTargets consensus.
- The proposed consensus to document SendTargets in
	the main part of the specification takes note
	of and hence overrides Larry Lamers's preference
	for documenting in an Annex.
Anyone who disagrees with the above statement of consensus
should post to the list.

There's one issue that's not completely clear to me from
the discussion, and that is how to limit the scope of
information that is returned by SendTargets to match what
I believe to be the sense of the discussion that SendTargets's
purpose is to describe the device/implementation/instance
to which it is issued. I can see a couple of choices:
(A) SendTargets only returns information about targets that
	are accessible through the <IP address, TCP port> to
	which the SendTargets was issued.
(B) SendTargets only returns information about targets that
	are accessible through an <IP address, TCP port> that
	can also access the *same* canonical iSCSI target
	instance to which the SendTargets was issued.
(A) is the simpler one to explain and understand, and may
do a better job of structuring the discovery process (new
iSCSI "instances" can't be discovered as a result of issuing
SendTargets) at the price of potentially having to discover
more iSCSI communication endpoints to which SendTargets
has to be issued at the earlier stage of discovery.  (B)
allows configuration to be centralized in some cases where
(A) does not, but the notion of "*same* canonical iSCSI
target instance" strikes me as hard to define and enforce
in a protocol spec, and opens SendTargets up to
virtualization of the canonical target (e.g., by
replication of state information) in a fashion that could
turn SendTargets into a network-wide discovery mechanism,
which seems contrary to the sense of the discussion.
(A) seems to be the choice that better fits what I
believe the sense of the discussion is.

Comments?

Thanks,
--David

> From:	Mark Bakke [SMTP:[email-masked]]
> Sent:	Wednesday, June 20, 2001 10:02 AM
> To:	John Hufferd
> Cc:	[email-masked]
> Subject:	Re: iSCSI: Wrapping up SendTargets
> 
> 
> This thread turned out more interesting than I had expected,
> but anyway, after reading through the messages sent while I
> was gone, it looks like we at least have some consensus on
> keeping SendTargets.
> 
> I would like to see John's option #2 as well.  Currently,
> SendTargets is documented in the naming & discovery document;
> where should we put it in the iSCSI spec?
> 
> We will also need to close on some of the previous threads
> about aggregation tags, iteration, etc.
> 
> It looks like we should continue the thread on the future
> (SLP, iSNS, etc.) discovery stuff, but I should have started
> that one separately.
> 
> --
> Mark
> 
> John Hufferd wrote:
> > 
> > iSCSI Team,

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 22 Jun 2001 17:13:20 -0700

..snipping..
> 	instance to which the SendTargets was issued.

I don't understand what you're thinking of here - SendTargets is intended
partly as a discovery mechanism.  Why would we limit it to only "only return
information about targets that are accessible through an <IP address, TCP
port>"?  

What's your concern about "same canonical target"??

> has to be issued at the earlier stage of discovery.

This defeats part of the intent of SendTargets?

> (B) allows configuration to be centralized in some cases where

The behavior outlined by the Naming and Discovery team for SendTargets is
dependant on what target name an initiator is logged into. 

SendTarget response: 
   **logged into 'iSCSI' target ->  repeating (list of targetname and 
     all associated paths to that name w/aggregation tags) 
     filtered by initiator access rights.

   **logged into <explicit target name> - should be 'report portal groups'
flavor of SendTargets where the information is limited to the information
about "the target being addressed" rather than a list of all accessible
targets for this initiator.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: [email-masked]
Date: Fri, 22 Jun 2001 20:59:01 -0400

Marj,

> What's your concern about "same canonical target"??

Suppose we have three independent iSCSI systems,
X, Y and Z.  My understanding of the sense of
the discussion is that the desired approach
is that an Initiator discovers via some other
means that it should talk to X, Y, and Z,
and then SendTargets on each system only returns
information about targets on that system.

Restricting SendTargets to only describe targets
accessible through the <IP address, TCP port>
on which it was issued prevents X from returning
information about Y and Z.  It also prevents
X from returning information about targets on
X that are only accessible through other IP
addresses and/or TCP ports.  This forces
more <IP address, TCP port> pairs to be
discovered prior to issuing Send Targets.

That may be a good thing - for example it makes
it possible for a management tool to figure out
where all of some Initiator's storage is without
ever issuing any SendTarget commands.  It would
be a "bad thing" if the only way to find Y was
to issue a SendTargets to X (e.g., simple
mistake in configuring X can hide Y from
the management tool, even if all the Initiators
still work).  This argument is somewhat less
compelling when we're dealing with two ports
on X instead of X and Y.

"same canonical target" was an attempt to deal
with the "It also prevents ..." sentence above.
The concern I have is about someone placing
information about X, Y, and Z on all of X, Y,
and Z, and then claiming that the "iscsi"
canonical target on X, Y, and Z is the same
target because the same information is returned
in each case.  This seems to make the "same
<IP address, TCP port>" approach preferable.

Does that make things clearer?  Do you see a
need for a SendTargets issued to system X to
return information about system Y?

Thanks,
--David

> From:	KRUEGER,MARJORIE (HP-Roseville,ex1) [SMTP:[email-masked]]
> Sent:	Friday, June 22, 2001 8:13 PM
> To:	[email-masked]'; [email-masked]
> Cc:	[email-masked]

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 25 Jun 2001 13:37:13 -0700

> addresses and/or TCP ports.

I don't see the value of this restriction.  

One method to implement an iSCSI solution might use a configuration utility
to specify a list of IP addresses representing separate targets (minimal
configuration information), and then expect that a SendTargets command
issued to the "iSCSI" target at these IP addresses to allow discovery of all
IP addresses and accessable targets that are a part of the reporting iSCSI
implementation.

If duplicate target information is 'discovered', it can be reconciled by
comparing target names.

The rules you've outlined would preclude this?

> This forces

How?

> ever issuing any SendTarget commands.

That might be 'nice', but not mandatory.

> It would

I wouldn't necessarily advocate such a solution, but it's implementation
dependant.  We MUST NOT dictate implementation.

> <IP address, TCP port>" approach preferable.

I don't see your concern here.  The "iSCSI" target name is not unique, does
not represent a fully functional target, and MUST NOT be compared to
determine 'target identity'.  That seems clear.  If different IP addresses
report the same information via SendTargets, the initiator's functional
sessions will be to the <full target names> reported.  What's the harm?  I'm
not advocating this approach, but if implemented correctly, it should work.

When we talk about SendTargets "returning a list of targets", we are mostly
thinking about the notion that a single iSCSI target node might chose to
export different capabilities (LUN maps, features?) by exporting multiple
target names.  I'm not sure anyone envisioned the scenario you outline, but
I don't see any real issues with it.

> Do you see a

No, but I see no reason to prohibit this.

-Marj

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 25 Jun 2001 17:52:35 -0700

> So, let me acknowledge Marj's position that use of SendTargets
> to describe other systems should be allowed, and solicit
> other comments on this issue.  In particular, I'd like to
> hear from those who want to make sure that SendTargets
> will be able to be retired in the future.

Well actually, my position is that SendTargets responses should be allowed
to include everything that you know about your own implementation, which may
include other TCP/IP addresses (aggregation tags included), and other target
names that your implementation exports.

If you allow this behavior, how do you preclude "targets reporting
information about other targets"?  How do you distinguish the two cases?

Marjorie Krueger

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 27 Jun 2001 13:18:53 -0400

Sorry if this is a repost, I sent this message Monday and didn't see it
posted:

> From: KRUEGER,MARJORIE (HP-Roseville,ex1) 
> Sent: Monday, June 25, 2001 5:53 PM
> To: [email-masked]'; KRUEGER,MARJORIE (HP-Roseville,ex1)
> Cc: [email-masked]
> Well actually, my position is that SendTargets responses 
> should be allowed to include everything that you know about 
> your own implementation, which may include other TCP/IP 
> addresses (aggregation tags included), and other target names 
> that your implementation exports.
> 
> If you allow this behavior, how do you preclude "targets 
> reporting information about other targets"?  How do you 
> distinguish the two cases?
> 
> Marjorie Krueger

---

From: "Jim Hafner" <[email-masked]>
Date: Wed, 27 Jun 2001 13:31:08 -0700

Folks,

Marj asks:  How do you distinguish the two cases (of reporting on stuff in
the same box and stuff in other boxes)?

I'd add: how do you test compliance?

I think the standard should define the protocol, describe what it is
intended to be used for (report about targets "in the same box"), and, if
necessary, add SHOULD NOTs to discourage use as a more general
environment-wide discovery mechanism.

Jim Hafner

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu
on 06/27/2001 10:18:53 am

To:   "Ips Reflector (E-mail)" <[email-masked]>
cc:
Subject:  RE: iSCSI: Wrapping up SendTargets