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

From: William Studenmund <[email-masked]>
Date: Wed, 3 Aug 2005 10:33:25 -0700

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 03 Aug 2005 17:58:48 -0700

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:
> parallel probes aren't parallel as sen by the target, then you will also 
> get this.
> 
> 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

---

From: William Studenmund <[email-masked]>
Date: Thu, 4 Aug 2005 10:50:41 -0700

On Aug 3, 2005, at 5:58 PM, Mallikarjun C. wrote:

> threads on this topic.  And that's why Bob Russell brought this to 
> this forum again to document and be done with it.

I guess my hope was to come up with one behavior/description which 
includes both cases. So we have one understanding, one rule, and 
different targets could choose different behaviors within this one 
rule.

> "consensus" for David hasn't called it) as far as I can tell from 

I'll be honest. I was part of that "conclusion" and I overlooked the 
TPGT aspect of it. :-)

> But I thought that was the problem we're trying to address with the 

I'm sorry, my original comment was aimed more at the thought that we 
had to make a tradeoff with one idea vs the other. I think we can find 
a common ground that will encompass all behaviors.

My thought is to refine what you say above. On a no-name discovery 
session, if a target does not return a TPGT, then the TPGT should be 
taken as "" or NULL (as you suggested). Then all targets do session 
reinstatement on no-name discovery sessions against other sessions with 
matching InitiatorName-ISID-NULL_TargetName-TPGT. So all portals that 
don't return a TPGT will reinstate with each other. All portals that 
return TPGT 0 will reinstate with each other, and so on. In essence we 
add "" or NULL to the TPGT space for discovery sessions, and the ISID 
rule applies.

Thus an initiator can figure out what the target is doing and it should 
not be surprised about what is happening.

I think letting/requiring targets to send a TPGT when they have a TPGT 
in mind (not "" or NULL) is an important change. Without it, the 
initiator would be shooting blind and could have little clue as to what 
the target is doing. I think that's bad. So bad that if we don't 
permit/require sending a TPGT when the target is acting like it is not 
"" or NULL, then I think we should go with option A. Otherwise I feel 
we would have a shooting-in-the-dark situation which feels very messy 
to me.

Take care,

Bill

---

From: "Ken Sandars" <[email-masked]>
Date: Mon, 8 Aug 2005 20:22:53 +0100

Gidday all, 

Sending the TPGT during the discovery login is not going to help the
multiple concurrent login situation as the information is too little too
late. The reality is that at start-up the initiator IS shooting in the dark.

The only information the initiator might know is the TCP addressing
characteristics of the portal(s) to attempt discovery on. It might not even
know if those portals are on the same network entity.

If it attempts multiple concurrent discovery logins to all its discovery
portals, then it will be in for a rude shock if it encounters a four-portal
network entity using option A!

Option B seems better, but say a network entity is configured such that two
portals have the same TPGT and another two have a different TPGT for the
spooky 'no-name' target. The first-time concurrent caller is going to see
session reinstatement between the paired portals.

I suggest that session reinstatement on unnamed discovery sessions should be
limited to the session on the same portal on which the new connection is
being made. In effect, operating like Mallikarjun's option B, but with each
portal in the network entity being assigned to its own portal group in the
"no-name" target node. 

What are we really trying to achieve by identifying session reinstatement
conditions? Is it just to free up resources at the target network entity?

Given the extremely restricted characteristics of discovery sessions,
resource-limited targets are not going to allow discovery sessions to hang
around for long if the initiator doesn't get on with issuing its SendTargets
TEXT pdu and logging out. I'm sure that more than one iSCSI target out there
drops inactive discovery sessions after a certain timeout.

Thoughts?
Ken Sandars
Adaptec, UK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of William Studenmund
> Sent: 04 August 2005 18:51
> To: Mallikarjun C.
> Cc: IPS
> Subject: Re: [Ips] Re: ISID and Discovery 
> Re:draft-ietf-ips-iscsi-impl-guide-00.txt
> 
> 
>