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

["Mallikarjun C." <cbm@rose.hp.com>]

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?

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

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

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.

....

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

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