Subject: iSCSI: Rev 07 Comments

From: "Bill Moody" <[email-masked]>
Date: Wed, 15 Aug 2001 16:16:04 -0500

I have a couple of points I'd like to raise concerning the 07 version of
the document.

Section 1.5.3.  On page 39, under 'iSCSI Initiator Requirements' the
term initiator portal group is used multiple times.  This is the first
use of this term and led to some confusion on my part.  The 'portal
group' term was clearly defined earlier and was used repeatedly in
connection with the target but no mention has been made of the use of
initiator portal groups prior to this point.  The ISID RULE clearly
defines that only one session with a given ISID can exist between a
given iSCSI Initiator and iSCSI Target Portal Group - it doesn't mention
initiator portal groups.  It would be nice to define this 'initiator
portal group' term prior to its use.

Appendix A.  What is the meaning of the value '11EDC6F41' in the table?
Is this the generator polynomial that is discussed in the following
paragraph?  If so, it is not clear.

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402

---

From: "Jim Hafner" <[email-masked]>
Date: Wed, 15 Aug 2001 15:01:35 -0700

Bill,

As a work-in-progress, my apologies for the confusion.

The iSCSI model defines portal groups as collections of network portals
that can coordinate (at it's end) multiple connections within a session.
That's true for the initiator side and the target side.  I had thought that
the defintion was initiator/target agnostic (I'll have to go back and read
it again, in context).

Keep in mind that there are two models playing here, the iSCSI model and
the SAM/SCSI model.   Portal groups are constructs of the iSCSI model and
are symmetric with respect to initiator or target.  The only non-symmetry
at the iSCSI level is in the identifiers for network portals.  Target
network portals have to have an ipaddress AND a listening tcpport (server
socket).  Initiator network portals don't "listen", so they only have
ipaddresses.

It so happens that as we've proposed the SAM/SCSI model overlay on iSCSI
constructs, only the target portal group plays a role; the initiator portal
group is "invisible" to the SAM/SCSI model.    Hence, the lack of emphasis
on the initiator portal group.  There is definite asymmetry here and we've
tried to justify the value in that in other postings.   When we get to
"initiator requirements", we start having to mention them for other reasons
(as has been discussed in other threads);  namely, where they get there
iSCSI Name and the ISID namespace they use.

Does that help?  And yes, this whole stuff will need a couple more careful
reading/rewritings to get it all correct and clear.

Jim Hafner

"Bill Moody" <[email-masked]>@ece.cmu.edu on 08/15/2001 02:16:04 pm

Sent by:  [email-masked]

To:   "IP Storage Mailing List (E-mail)" <[email-masked]>
cc:   "Robert Griswold" <[email-masked]>, "Bill Moody"
      <[email-masked]>
Subject:  iSCSI:  Rev 07 Comments

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402

---

From: Rick Ellis <[email-masked]>
Date: Wed, 15 Aug 2001 16:22:23 -0700

>that can coordinate (at it's end) multiple connections within a session.

Why did that happen?  Wouldn't it have been a lot simpler to not allow
multiple connections within a session?  It has really complicated the
protocol.

---

From: "Bill Moody" <[email-masked]>
Date: Thu, 16 Aug 2001 06:45:45 -0500

Jim,

Thanks for the clarification.  You're right in that the definition of
Portal Groups is initiator/target agnostic.  I was able to resolve my
own confusion after re-reading the definition and considering the
implications a few times.  I just thought you might avoid any such
confusion by explicitly mentioning the notion of initiator portal groups
sooner.  Although the definition is agnostic, the diagram that follows
the definition is target specific and no mention of initiator portal
groups occurs until the discussion following the ISID RULE.

Bill
-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 5:02 PM
To: Bill Moody
Cc: [email-masked]
Subject: Re: iSCSI: Rev 07 Comments

Bill,

The iSCSI model defines portal groups as collections of network portals
that can coordinate (at it's end) multiple connections within a session.
That's true for the initiator side and the target side.  I had thought
that
the defintion was initiator/target agnostic (I'll have to go back and
read
it again, in context).

Keep in mind that there are two models playing here, the iSCSI model and
the SAM/SCSI model.   Portal groups are constructs of the iSCSI model
and
are symmetric with respect to initiator or target.  The only
non-symmetry
at the iSCSI level is in the identifiers for network portals.  Target
network portals have to have an ipaddress AND a listening tcpport
(server
socket).  Initiator network portals don't "listen", so they only have
ipaddresses.

It so happens that as we've proposed the SAM/SCSI model overlay on iSCSI
constructs, only the target portal group plays a role; the initiator
portal
group is "invisible" to the SAM/SCSI model.    Hence, the lack of
emphasis
on the initiator portal group.  There is definite asymmetry here and
we've
tried to justify the value in that in other postings.   When we get to
"initiator requirements", we start having to mention them for other
reasons
(as has been discussed in other threads);  namely, where they get there
iSCSI Name and the ISID namespace they use.

Does that help?  And yes, this whole stuff will need a couple more
careful
reading/rewritings to get it all correct and clear.

Jim Hafner

"Bill Moody" <[email-masked]>@ece.cmu.edu on 08/15/2001 02:16:04
pm

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402

---

From: "Jim Hafner" <[email-masked]>
Date: Thu, 16 Aug 2001 08:24:01 -0700

Rick,

There is no doubt that limiting to one connection per session would have
made this whole thing a lot simpler.  However, the consensus was declared
to be that the value of multiple connections dominated the extra complexity
involved.    Consequently, the model has to reflect what is reasonable
given the possible implementation choices for such a complex environment.
That led us to where we are with the model....

Jim Hafner

Rick Ellis <[email-masked]>@ece.cmu.edu on 08/15/2001 04:22:23 pm

To:   [email-masked]
cc:

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 16 Aug 2001 18:30:22 +0300

will fix - thanks - Julo

"Bill Moody" <[email-masked]>@ece.cmu.edu on 16-08-2001 00:16:04

Please respond to "Bill Moody" <[email-masked]>

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402