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

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

Mallikarjun,

My "text" again isn't conveying what I'm thinking, but yours is closer.  I
want the model to allow physical things to span multiple virtual things.
What I was trying to convey is exactly what you're saying.  Is it more
clear if I had said "can live in multiple portal groups *so long as each
portal group was in a different node*"?  But I want a network portal (be it
either physical or virtual) to "connect up" to different nodes (through
unique portal groups on each node).

If a network portal has only one ipaddress/[tcpport], it can service
multiple nodes, but belong to only one portal group per node.  So, maybe
this multi-node (focused on only one network portal) picture helps:

    NodeA           NodeB          NodeC
      |               |              |
PortalGroupA1   PortalGroupB2  PortalGroupC1
      |               |              |
      |_________NetworkPortalX_______|
            (Ipaddress/[tcpport])


The picture doesn't show other portal groups that might be in any of the
nodes nor does it show other network portals that might be in any of the
portal groups.   This is the tree view from a given network portal up.
The up-degree at the network portal can be anything.  The up-degree of each
portal group is one.  There's a different view from the node down.   In the
node-down graph, I can have any number of portal groups below a node and
any number of network portals in each portal group.  The rule is that this
graph is a tree.

And the model allows the leaf structure of one node-down tree to be related
in any way to the leaf structure of another node-down tree.  [I'm finding
it hard to describe this clearly.]  By example:  suppose that PortalGroupA1
above had another NetworkPortalY in it (within NodeA).  This network portal
need not be in PortalGroupB2 of NodeB just because NetworkPortalX was in
PortalGroupB2 .  So the fact that two leaves of one node-down tree are in
one portal group (have a common parent) does not require those two leaves
to be in the same portal group (have a common parent) of another node-down
tree.

Did I make any thing more clear or just muddle things up?

And yes, the scope of the portal group tag is the node.

The tricky part in this is the viewpoint.  If you think only one node at a
time, then the node-down tree is easy enough to describe.  It's when you
try to put more nodes in the picture that the relationships get more
complicated.   I'm not even sure it's possible in 2D to render in one graph
the full set of possibilities even with two nodes!

Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com> on 08/15/2001 10:40:16 am

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,

As you say, I too think we are very close on this.  Let me comment
on one sentence in your message that I didn't quite follow.

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

Two comments -
- My understanding of portal groups has been that they are disjoint
  sets, and that's the reason a session could not span multiple portal
  groups.  You seem to suggest that portal groups are overlapping sets
  with possibly common network portals, or did I misunderstand?

- By saying "a portal group only belongs to one iSCSI node", if you
  are implying that the scope of the portal group tags is per iSCSI
  node (i.e. the tags are unique and meaningful within one iSCSI node),
  then I am fine.  I just want to confirm that you are not excluding the
  possibility of one *physical* portal group (say an HBA) being able
  to get to multiple (virtual) iSCSI nodes.

Regards.
--
Mallikarjun


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668   Hewlett-Packard, Roseville.
cbm@rose.hp.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
>
>
>