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

From: "Galloway, Bill" <[email-masked]>
Date: Thu, 4 Aug 2005 01:16:14 -0500

I am very much in favor of allowing both.  I can see why some targets do
not want to implement the more complicated option B.  For those targets
that have multiple independent ports for fault tolerance, option A is
nearly impossible to implement and that target would take on the burden
of option B.

Bill Galloway

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mallikarjun C.
> Sent: Wednesday, August 03, 2005 7:59 PM
> To: IPS
> Subject: Re: [Ips] Re: ISID and Discovery 
> Re:draft-ietf-ips-iscsi-impl-guide-00.txt
> 
> Bill,
> 
>  > Why though do we have to mandate one or the other?
> 
> That is a good question.  I thought this was found to be an 
> interoperability issue in the past, as evidenced by multiple email 
> threads on this topic.  And that's why Bob Russell brought 
> this to this 
> forum again to document and be done with it.
> 
> Option A, BTW, was the earlier list "conclusion" (I'd stay away from 
> "consensus" for David hasn't called it) as far as I can tell from 
> previous email threads.
> 
> As you suggest, we can say:
> a) some targets do no-name discovery session reinstatements and some 
> don't, on matching InitiatorName-ISID;
> b) some targets return TPGT on no-name discovery sessions and 
> some don't.
> 
> But I thought that was the problem we're trying to address 
> with the guide.
> 
> I suggest it is time to call the consensus on the topic and move on.
> 
> 
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> William Studenmund wrote:
> > On Jul 29, 2005, at 6:01 PM, Mallikarjun C. wrote:
> > 
> >> 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.
> > 
> > 
> > My vote is for option B, though we don't use the language 
> of "No-Name 
> > iSCSI node."
> > 
> > Why though do we have to mandate one or the other? While our target 
> > isn't one of them, I believe there are targets where TPGT 
> would not be 
> > defined in a no-name discovery session. So I don't mind us doing 
> > something to help them. I'd just rather we permit targets 
> that would 
> > have a TPGT available to them to use it.
> > 
> >> 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.
> > 
> > 
> > As above, this is our current behavior.
> > 
> >> 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).
> > 
> > 
> > Well, if the probes happen sequentially, you'll get the 
> same result of 
> > multiple overlapped data. Or if the races happen just right 
> that the 
> > parallel probes aren't parallel as sen by the target, then 
> you will also 
> > get this.
> > 
> >> 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.
> > 
> > 
> > While this is true, is this really a problem? This notion 
> does not need 
> > to manifest itself as any code or data structures. All it 
> means is that 
> > no-named discovery sessions may have a reinstatement spam 
> smaller than 
> > the whole network entity. Option A is just the simplest 
> case of this.
> > 
> > The one thing that we may wish to do is permit the 
> TargetPortalGroupTag 
> > to be returned for no-name discovery sessions. For targets 
> that have 
> > more than a "" TPGT for no-name discovery sessions for the 
> whole network 
> > entity (something that isn't case A), then perhaps we 
> should have the 
> > targets return the TPGT.
> > 
> > Take care,
> > 
> > Bill
> 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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

---

From: "Elliott, Robert (Server Storage)" <[email-masked]>
Date: Thu, 18 Aug 2005 13:31:11 -0500

> Sent: Wednesday, July 27, 2005 6:45 PM
> To: IPS
>  > So while the RFC permits zero, SAM does not.
> 
> Thanks for pointing this out.  Rob Elliott though noted the following 
> offline on my prompt: a) That is just an informative annex in SAM-nn, 
> not normative, so other documents can override it, and b) The 
> existing SAM-nn text is historical (until iSCSI rev13 or so, we 
> required it to be between 1-65535).  Rob also volunteered to move a 
> T10 proposal to sync up the SAM-4 wording to RFC 3720 (thanks Rob!).

T10 proposal 05-301r0 has been posted to http://www.t10.org/new.htm (and
http://www.t10.org/doc05.htm) to get rid of the out-of-date "non-zero"
statement about portal group tags in SAM-4.  It will be discussed in the
September T10 CAP WG meeting.

--
Rob Elliott, [email-masked]
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott