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

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

Mallikarjun,

We are very close on this stuff.   A few more comments inline.

Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com> on 08/14/2001 03:38:53 pm

Please respond to cbm@rose.hp.com

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: rev07 - ISID-TSID & naming comments



Jim,

Thanks for the quick response.  I agree with most of your responses.
However, some comments below on your responses.

Regards.
--
Mallikarjun

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

Jim Hafner wrote:
>
.....

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

I agree with what you state, but I don't quite see why the suggested
sentence
violates this philosophy.  If you substitute "<InitiatorName+ISID>" for
the
phrase "initiator SCSI port" (since they are the same) in my suggested
sentence,
that's essentially what you state above...  Did I miss something?

<JLH>
Not to be too technical, but the two quoted things aren't actually the
same, one is the name/identifier for the other, but that's nit-picky.  Now
that I re-read your sentence a couple of times, I think I have a better
understanding of where you're going with it and I have less problem with
it.  Though it is literally correct in that the target does assign it and
it ends up pairing with an initiator SCSI port, I think I'm bothered by the
implication that this is a SCSI level tag.  It's really just an iSCSI level
tag, and so is more naturally paired with the I-Name+ISID to identify a
session.  So, I'd prefer (but not strongly) "The TSID is a target-defined
tag assigned to a session to identity that session along with the initiator
Name and ISID" or something like that.  My point is that it's there to
identify the iSCSI session and is independent of the SAM-iSCSI mapping.
But I won't get bent out of shape if the words you propose are used.
</JLH>

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

Okay, I see your point.  I don't have a strong opinion on this.  It just
appears to me that it's simply easier to visualize a network portal with
an
IP address, than with a higher abstraction (DNS name) possibly resolving
into multiple IP addresses.

<JLH>
With your discussion below, I think I'm coming to agree with you on this.
It might as well stay as simple as possible.
</JLH>


Your description however, of a virtual network portal spanning multiple
NICs
doesn't come across in the current Network Portal definition, nor do I
see the
need for such a construct.  It appears to me that you could instead call
such
a virtual portal as a portal group, decomposable into a bunch of portals
each
associated with one <IPaddress+TCP port> - since the notion of a poral
group and
its identifier (tag) is already defined in iSCSI.

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

OK, I didn't realize that it's still under debate.  My personal
preference
is to mandate the exchange of iSCSI-Names always (in the login command
PDU
itself), and then differentiate a discovery session only based on the
SessionType key - unless some issues were discovered in NDT with this
simplistic approach.

<JLH>
However, there was a move to not require a target name for a Discovery
session since the point of that session was to discover names (and
addresses).  Hence there's talk of reserving the name "iscsi" for future
use.  I'm personally ambivalent on this one.  In either case, the words
have to reflect what is decided an that's not the case at the moment.
</JLH>

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

Agreed, I am not arguing for symmetry in my comment.  I was merely
pointing out
the non-definition of what you just mentioned in the last sentence as
"initiator
network portal"!

<JLH>
So a definition of initiator network portal is a network portal with just
an ip address and no listening port.
</JLH>


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

Yup, I was hinting that what's implied by the picture could be the
answer
to my own previous question on "initiator network portal".  Just wanted
to
confirm.

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

I agree that nexus identifier appears more an implementation issue.  The
only
reason I thought it might make sense for iSCSI to call it out is because
of
draft's reference to "parallel nexus" (comment below).  My immediate
inclination
was to say "two nexus are parallel if their nexus identifiers are the
same" -
that led to this query on what's a legitimate nexus id for an
implementation
in order to ensure that it doesn't establish parallel nexus during
runtime.

<JLH>
I'm not sure if your quoted definition is going to be the case when SAM-3
evolves, or it may be that that's exactly what the definition will be.  Who
knows!  There are two choices for a definition of parallel nexus (a) nexus
identifiers are the same (b) between the same two SCSI ports. For our SAM-2
purposes, I don't think it matters.  And I don't have a problem with either
definition.  They come out the same in both cases, so long as we have a
definition of I_T nexus identifier as using the target portal group tag.
</JLH>

BTW, my understanding of an I-T nexus has been that it's a two-tuple -
<initiator SCSI port-identifier, target SCSI port-identifier>.  So, I
guess I'd
agree with your first option, since iSCSI defines port identfiers the
same as
port names.

<JLH>
Well, that's a good definition of I_T nexus identifier but a nexus is a
"relationship" not a name/identifier... :-{)
</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>

Sorry, I was referring to a post-rev07 word doc on the plane for typing
up these
comments.  Your guess is probably right - that it is a misplaced
sentence.  The
document that I was referring to explicitly states that iSCSI mandates
SCSI Device
name support and SCSI Port name support - except it put the latter
requirement
in the SCSI target port discussion.

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

I completely agree with these sentiments.  My suggested sentence does
not
preclude implementors from defining one iSCSI Node per HBA, only that
they
share the same iSCSI-Name *if* they decide to act together as one iSCSI
Node.
I don't see that as any different from what you described above...

So, I guess the question is: do you see it as a hard requirement *if*
multiple
portal groups are implemented as one iSCSI Node?  My take is "yes",
hence the
suggestion.

<JLH>
Yes, I think I agree here.  But there are subtleties in how we word this.
We have to make sure the words don't preclude a network portal functioning
on behalf of multiple iSCSI nodes.  Perhaps if we can make it clear that a
network portal can live in multiple portal groups, but a portal group only
belongs to one iSCSI node, then we're OK.

The other issue is the notion of an implementation requirement.  If the
model says "portal groups are in the same node if and only if they expose
the same iSCSI name", then there isn't any other implementation choice so
no explicit requirement is needed.  If one says Bob and one says Alice,
then they are in different Nodes, but if they both say Bob, then they are
in the same node.  The questions are more of "why do they say the name they
say? where does the name come from? how can I get the name to live at the
OS-image layer? ...".  So the intent of this sentence in the draft is to
encourage configuration APIs from outside the hw so that an OS can have a
single node image.  That's not a hard requirement really.

I think we're on the same page here as far as the model is concerned.  I
think we're both fishing for words that meet the "upper level" view of what
the name should be attached to, so that we get the functionality we want.

I'll keep these thoughts in mind when reviewing the draft for alternative
wording.
</JLH>



Similar comments apply for other suggestions below.  Please comment.

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