Re: iSCSI: Wrapping up SendTargets

["John Hufferd" <hufferd@us.ibm.com>]

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

           Define ReportPortalGroups functionality as a subset
           of SendTargets.

  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: hufferd@us.ibm.com


Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 06/08/2001 01:31:16 PM

Sent by:  owner-ips@ece.cmu.edu


To:   IPS <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: Wrapping up SendTargets




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
mbakke@cisco.com
763.398.1054