|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Rev 07 CommentsJim, 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:hafner@almaden.ibm.com] Sent: Wednesday, August 15, 2001 5:02 PM To: Bill Moody Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Rev 07 Comments 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" <bmoody@Crossroads.com>@ece.cmu.edu on 08/15/2001 02:16:04 pm Sent by: owner-ips@ece.cmu.edu To: "IP Storage Mailing List (E-mail)" <ips@ece.cmu.edu> cc: "Robert Griswold" <rgriswold@Crossroads.com>, "Bill Moody" <bmoody@Crossroads.com> Subject: iSCSI: Rev 07 Comments 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
Home Last updated: Tue Sep 04 01:04:00 2001 6315 messages in chronological order |