|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: New Suggested Wordage to cover TPGTsSantosh, (I also omitted the fact that Mallikarjun was also part of the agreement.) All these items were examined, in a lot of detail, and we think the wordage was a reasonable compromise (no one got every thing they wanted). Especially since many folks did not believe there was a "real" problem (but we do not want us to dig that up again). This was a painful deal but, we have a deal, that we are committed to support. And unless it is broken, we do not want to adjust it further. I you want further explanation, please contact me off the list, and I will take you through the details (a number of folks have told me today that they were bored with this topic.) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 03/18/2002 02:30:20 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: New Suggested Wordage to cover TPGTs Hello, Thanks for addressing this issue. Some comments inline. Regards, Santosh John Hufferd wrote: > > The Naming and Discovery Team (NDT) and Julian, have had meetings on the > issue > of TPGT. These meetings were to address the TPGT issue express on this > reflector. The following is the recomendation of the extended NDT: > > In section 4.3 (possibly as the last paragraph on page 63 of rev11) - > > The first Login Response PDU during the Login phase from the iSCSI target > SHOULD return the TargetPortalGroupTag key that contains the tag value of > the iSCSI portal group servicing the the Login Request PDU. Can we alter the above SHOULD to MUST and remove the sentence below ? Is there any target out there that will not support the addition of a network portal into a portal group ? (At least the initial configuration of a target involves the addition of a portal to a portal group ?) To reduce options and keep the authentication foolproof, it would be good to mandate that the targets return their TPGT. Not doing so will expose initiators to the whims of the target implementation. The authentication is desired by the initiating side and it must have control over the ability to authenticate. Hence, if we cannot mandate that targets always send their TPGT in login response, one of the below 2 approaches are possible alternatives, which give the initiator control over the authentication : 1) Initiators that are interested in authentication send a TargetPortalGroupTag=? in their login request to query the target for its TPGT and authenticate the response. Target MUST respond with the current TPGT for that network portal. 2) Initiators send the intended destination TPGT as a part of the login request and the target MUST authenticate the intended TPGT with the current TPGT. On an authentication failure, target MUST reject the login. Both of the above alternatives allow the initiator to ensure that authentication is performed, instead of depending on the target to support sending its TPGT in the login response. > If the iSCSI > target implementation supports altering the portal group configuration > (including adding, deleting, and swapping of portals in a portal group), it > MUST return the TargetPortalGroupTag key carrying the tag value of the > servicing portal group. > If the reconfiguration of iSCSI portal groups is a > concern in a given environment, the iSCSI initiator MUST use this key to > ascertain that it had indeed initiated the Login phase with the intended > target portal group. To reduce options and keep the authentication process foolproof, suggest making this authentication un-conditional. i.e. Remove "If the reconfiguration of iSCSI portal groups is a concern in a given environment," > > In chapter 11 (possibly as section 11.5) - > > 11.5 TargetPortalGroupTag > > Use: IO by target, Declarative > Senders: Target > Scope: SW > > TargetPortalGroupTag=<integer-from-0-to-65535> > > Examples: > TargetPortalGroupTag=1 > > Target portal group tag is a 16-bit integer that uniquely identifies a > portal group within an iSCSI target node. This key carries the value of > the > tag that is servicing the Login request. The iSCSI target returns this key > to the initiator in the first Login Response PDU. > For the complete usage expectations of this key, refer to section 4.3. -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ##################################
Home Last updated: Tue Mar 19 09:18:47 2002 9196 messages in chronological order |