Re: iSCSI: rev07 - ISID-TSID & naming comments

["Jim Hafner" <hafner@almaden.ibm.com>]

Mallikarjun,

Some comments in-line.  In general, however, most of your comments are
right on.  This part of the draft is essentially and rev0.0.0.1 :-{) and
needs cleanup (and as the contributing author, I thought I should respond).
Thanks for reading this so carefully.

I'm planning on collecting a lot of these comments (I have others from
other people), and running a rev of the text sometime soon.

Thanks again,
Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/14/2001 12:23:22 pm

Please respond to cbm@rose.hp.com

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


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: rev07 - ISID-TSID & naming comments



Julian,

Some comments in this area.

- Section 2.10.6, last sentence in para 1 states "An initiator is
uniquely
  identified by the value pair (InitiatorName, ISID).".  Suggest s/b
"initiator"
  with "initiator SCSI port".
<JLH>
Yes.  In fact, there are (were?) inconsistent use of the term 'initiator'
throughout the document.  Hopefully, that can get cleared up.
</JLH>

- Section 2.11.4, first sentence.  "The TSID is an initiator identifying
tag
  set by the target." s/b with "The TSID is a target-defined tag
assigned to
  an initiator SCSI port.".
<JLH>
This is actually an incorrect interpretation.  In the model we (I) am
proposing, the TSID has nothing to do with identifying either the target or
initiator SCSI port.  It is a tag used by the target (iSCSI target) to help
identify a session *along with the ISID* of that session.  In the model,
the TSID plays no role in the SCSI layer.

This sentence needs clarification.
</JLH>

- Section 1.5, para 1, "Network portals (IP names, addresses and TCP
ports)"
  Suggest dropping "IP names" since what really matters is just the IP
addresses
  and TCP ports.  IIRC, two DNS names can resolve to the same IP
address, and one
  DNS name can resolve to multiple IP addresses.
<JLH>
But IPnames (because of DNS) can be perfectly good identifiers for Network
portals.  The network portal can be virtual (shared across many nics that
have different IP addresses) or physical (used by a single nic that has a
unique address).  It all depends on the mapping.  The point here (and it
isn't that critical a point) is that I can initiate a connection to a
network portal (say in software) by openning a socket to a given
"IPnamed:tcpport" combination and let the lower layers deal with address
resolution.

On the other hand, I have no real problem with your suggestion, if you
think it simplifies things.
</JLH>

- The section in general is not consistent in the usage of iSCSI Name.
It uses
  "iSCSI name" "iSCSI Node name", and "iSCSI Name".  I would suggest
using
  a consistent phrase wherever iSCSI-defined Names are used, like
"iSCSI-Name".
  Simlar comments  apply for "Network Portal".
<JLH>
Agreed.
</JLH>

- Section 1.5.1, description for "Network Entity" has "This device or
gateway
  may support one or more iSCSI Node" s/b with "This device or gateway
may
  support one or more iSCSI Nodes and one or more Network Portals".
Similarly
  for "The iSCSI Node is accessed via a network portal", s/b with "The
iSCSI
  Node is accessed via one or more network portals".
<JLH>
Sounds OK to me.
</JLH>

- Section 1.5.1, description for "iSCSI Node".  The reasoning offered
for the
  definition for iSCSI-Names is not quite right.  Suggested sentence
"iSCSI-Names
  are required because multiple iSCSI Nodes may be present behind a
given
  combination of IP address and TCP port.".
<JLH>
OK too.
</JLH>

- Section 1.5.1, second para under "iSCSI Node" discussion, first
sentence.  This
  states that names are not required for default node access.  Is this
still true?  I
  thought we are  mandating InitiatorName and TargetName text key
exchange now.
<JLH>
I think this will have to be massaged in the direction you're going.
There's been some flux about this requirement.  At the moment, the
requirement (I think) is that for full function login names are required.
For a Discovery session, names are not.  When that gets finalized, this
wording can be adjusted as well.
</JLH>

- Section 1.5.1, description for "Network Portal".  Suggest rewording
the very first
  sentence to include the  last sentence.  The current first sentence
appears very
  vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
network
  portal for a target to comprise the "listening TCP port", should we
identify what
  it is for an initiator?
<JLH>
The initiator doesn't have the listening TCP port in it's network portal
definition because the initiator doesn't listen. Once a session
(connection) is created the listening port on the target side is out of the
picture and the connection goes to other ports that bind to the connection.
So, there is a definite asymmetry here between a target network portal and
an initiator network portal.
</JLH>

- The picture shown at the beginning of section 1.5 does not show TCP
port
  being part of the Network Portal on the initiator side.  Is it then
implied that
  only the IP address constitues a Network Portal for an initiator iSCSI
Node?
<JLH>
See the previous comment.
</JLH>

- Section 1.5.2, last para.  This defines the I-T nexus as the session
for iSCSI.
  This doesn't suggest a nexus identifier - is it the four tuple
<InitiatorName,
  ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
it both
  - the four-tuple being nexus id at the SCSI layer, and the latter at
the iSCSI
  layer?
<JLH>
There really is no strong need to define a nexus identifier as it never
really surfaces anywhere in the protocol.  There are two choices for the
identifier, one is the 4-tuple you suggest (the one with target portal
group tag), the other is the two names together with the session ID.  The
first builds a nexus identifier from the identifiers of the two SCSI ports
involved.  The other builds the nexus identifier from protocol layer things
(TSID, in particular which does not identify a SCSI port).   The importance
of the nexus identifier is really an internal implementation issue.  We can
call it either one.  For the moment, I'd lean towards the first option, but
SAM-3 (the future) may think that the second is a better choice.
</JLH>

- Section 1.5.3, second para with the ISID RULE, last sentence.  Suggest
"...nor
  does it preclude other sessions with different ...." s/b with "...nor
does it
  preclude multiple sessions with different....".
<JLH>
Fine
</JLH>

- Section 1.5.3, third para.  This mentions the term "parallel nexus".
I assume
  the equivalence of two 4-tuples is what is being implied here.  Unless
this term
  is already defined in some latest SCSI documents, I suggest defining
this as
  such.
<JLH>
It's not defined in any SCSI documents because it's never been physically
possible before!  A definition in my mind would be "two nexus are parallel
if they are independent relationships between the same two SCSI ports" (or
something like this).
</JLH>

- Section 1.5.2 does not comment on if iSCSI mandates the support of
SCSI Port names
  for iSCSI initiators (the requirement appears only the iSCSI targets
para).
  I assume it is mandatory.
<JLH>
I'm not sure what you're asking for here.  Perhaps this is just a misplaces
sentence.  SAM-2 now has the notion defined of SCSI port names and the
protocol can define what they are and if they are mandatory.  I'm sort of
assumed that by defining what they are (for the initiator as iSCSI
Name+ISID and for the target as iSCSI Name+Portal group tag) that they are
implied to be mandatory.

Did I miss something?
</JLH>

- The following initiator requirement:
"The iSCSI Name should be configurable parameter of each initiator
portal group."
   would be more clear if stated as (if this is a correct
interpretation):
"All the initiator portal groups of one iSCSI Node MUST share the same
 iSCSI-Node name."
<JLH>
Yeah, that's pretty much a requirement, in that if the names are different,
then the portal groups are not in the same iSCSI node.  What this sentence
(and the related sentences) are aiming for is less of a requirement (this
is a more recent understanding that hasn't made it into text yet) than a
prefered common API for people building hardware.  If my host has multiple
iSCSI hardware cards, in order that they coordinate the same iSCSI node
concept, then they should get their iSCSI name from outside -- i.e., be
configurable.  This is not a hard requirement because each could act on its
own as separate iSCSI node.  Unfortunately, that management/configuration
nightmare in FC is what this sentence is hoping to preclude.  We need to
find the right words to back away from this as a hard requirement and more
as request to implementors that this be available.

The same logic applies to the ISID and TSID partitioning, though in a
somewhat different way.  There are two assumptions that are at the root of
this rule: (a) no parallel nexus and (b) the session identifier for a
session is unique between two given iSCSI nodes.  The partitioning rules
(if implemented by the hw cards as an API) enable the least amount of
coordination required among different hw components.  For example, to
enforce (b), the target portal groups don't need to share the set of SIDs
that are active. They each own a portion of the name space and can use that
as they wish, regardless of what's happening on the other portal groups.
For (a), if the ISID name space is partitioned, then no two initiator
portal groups would ever attempt a login with the same target portal group
reusing the same ISID (so fewer rejected login's because the target portal
group is enforcing the ISID rule).

In short, (and I'm the first to admit this), we need very different
language to convey this idea.  It's more a "request to implementors" to
make life easy for everybody (easier management, easier target
implementations, fewer rejected logins, etc.) than it is a hard
requirement.  The two assumptions above and the resulting ISID RULE are
requirements.  The others are facilitators to that end.
</JLH>

   Similar comments apply for the target requirement.
- The following initiator requirement:
"The ISID name space of the iSCSI Initiator should be partitioned among
the initiator
 portal groups."
   would be better stated as (if this is a correct interpretation):
"All initiator portal groups of one iSCSI Node MUST share an ISID name
space
 for sessions established to one iSCSI target node.  Sessions
established to
 multiple iSCSI target nodes MAY share one ISID name space."
<JLH>
As I've indicated above, this is only part of the equation.  The ISID name
space is already scoped by the iSCSI Name.   The issue is facilitating
enforcement of the ISID rule and minimal cross hw implementations.
</JLH>



- The following target requirement:
"The TSID name space of the iSCSI Target should be partitioned among the
target
portal groups."
   would be better stated as (if this is a correct interpretation):
"All target portal groups of one iSCSI Node MUST share an TSID name
space for
sessions established to one iSCSI initiator node.  Sessions established
to
multiple iSCSI initiator nodes MAY share one TSID name space."
<JLH>
See previous two comments.
</JLH>

--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com