Subject: RE: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt

From: "Galloway, Bill" <[email-masked]>
Date: Fri, 29 Jul 2005 22:11:25 -0500

Mallikarjun,

If I understand you options correctly I would like to see Option B.

We have a product that has multiple hot-plug scsi ports.  For normal
session logins, these separate ports have nothing to coordinate since
each is its own portal group.  I have no idea how to reinstate a
discovery session on one hot-plug port when the same initiator tries to
do a discovery login on the other hot-plug port (with a different CPU).

One other minor problem with option A is that TPGTs could not be
Node-scoped since multiple nodes can live behind a single Network
Portal.

Bill Galloway

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mallikarjun C.
> Sent: Friday, July 29, 2005 8:02 PM
> To: IPS
> Subject: Re: [Ips] Re: ISID and Discovery 
> Re:draft-ietf-ips-iscsi-impl-guide-00.txt
> 
> OK, I see two options in dealing with TPGTs.  I sketched out 
> the options 
> and respective implications below as I see them.  Since I plan to 
> mandate one of the two based on the list feedback in the 
> Implementer's 
> guide, please review carefully - your initiator, target or 
> NIC *may be* 
> affected.
> 
> I personally am leaning towards Option A because I see it's 
> closest to 
> RFC 3720 semantics and would require no new conceptual additions.
> 
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> Options:
> 
> A. TPGTs are always Node-scoped.  If Node name isn't specified in the 
> discovery Login Request PDU, TPGT is meaningless and can't be 
> inferred 
> (or inferred to be invalid).
> 
> B. TPGTs are always Node-scoped.  If Node name isn't specified in the 
> discovery Login Request PDU, a special "No-Name" iSCSI Node 
> is implied. 
>   This No-Name iSCSI Node has its own TPGT numbering space - 
> one tag for 
> each physically possible portal group - and thus the TPGT can 
> be inferred.
> 
> Implications -
> 
> Option A:
> 
> 1. There can only be one no-named discovery session to a 
> Network Entity 
> with a given InitiatorName-ISID combination. A new no-named discovery 
> session reinstates the first.  If this is your current 
> behavior, speak up.
> 
> 2. An initiator doing parallel discovery probing of multiple IP 
> addresses using a generic InitiatorName-ISID tuple may see 
> all but one 
> of its probe attempts fail in each set of IP addresses hosted by one 
> Network Entity (if you're doing SLP/iSNS-based discovery, 
> this may be a 
> no-op).
> 
> 3. To realize the session reinstatement of a no-named 
> discovery session 
> on matching InitiatorName-ISID, target CPU software may have to be 
> involved in Login processing for no-named discovery sessions. 
>  Depending 
> on your implementation, it may not all be offloaded to hardware.
> 
> Option B:
> 1. There can be multiple no-named discovery sessions to a 
> Network Entity 
> with a given InitiatorName-ISID combination - one for each 
> TPGT of the 
> No-Name Node. A new no-named discovery session reinstates an existing 
> discovery session only if the TPGT matches.  If this is your current 
> behavior, speak up.
> 
> 2. An initiator doing parallel discovery probing of multiple IP 
> addresses using a generic InitiatorName-ISID tuple may have all 
> successful probes, but all such probes of each set of IP addresses 
> hosted by one Network Entity return duplicate discovery data 
> (if you're 
> doing SLP/iSNS-based discovery, this may be a no-op).
> 
> 3. For some implementations, it is technically feasible to 
> offload the 
> login processing for a no-named discovery session.  Target 
> CPU software 
> is not required to be involved (although your code may have other 
> reasons to get involved).
> 
> 4. Introduces a new notion of a "No-Name" iSCSI Node that 
> must host all 
> physically possible portal groups.  No-Name Node is however not a 
> full-fledged Node because TargetPortalGroupTag must not be returned - 
> though it can be inferred - on no-named discovery sessions 
> per RFC 3720, 
> and is limited to hosting only the no-named discovery sessions.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips