Subject: RE: [Ips] Discovery reinstatement

From: [email-masked]
Date: Thu, 1 Sep 2005 11:57:48 -0600

John, I've been thinking the same thing. Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Hufferd
Sent: Thursday, 01 September, 2005 10:09 AM
To: Mallikarjun C.; IPS
Subject: RE: [Ips] Discovery reinstatement

I guess I do not understand why anyone cares about the reinstatement of
a discovery session.  It was suppose to be simple and straight forward.
I don't thing any of us thought that the discovery session was so
important that it needed reinstatement.  It does a very simple thing,
has no direct relationship to any application, and has no direct impact
on the operation of a SCSI I/O command.  Further, it is easy enough to
just restart without having any state from a previous connection.  I see
no reason to make this complicated and then have the implementers bother
with add'l lines of code, and tests, including the interoperation test.

The reinstatement was intended for normal connections that could be
carrying SCSI I/O operations, and we wanted to avoid the SCSI level
error recovery.

I suggest that we keep this discovery stuff real simple and just have
the initiator restart the Discovery session (from Scratch) if a problem
occurs.  I also think that if for some reason an installation needs a
more robust discovery process, that they use something like iSNS.

.
.
.
John L Hufferd
Sr. Executive Director of Technology
Brocade Communications Systems, Inc
[email-masked]
Office Phone: (408) 333-5244; eFAX: (408) 904-4688
Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ken Sandars
Sent: Wednesday, August 31, 2005 12:57 PM
To: 'Mallikarjun C.'; 'IPS'
Subject: RE: [Ips] Discovery reinstatement

Hi Mallikarjun,

I like your approach to this problem. In my mind the answer to question
1 is
a strong yes, however, I do not like the clause about Network Entity.

>From my last posting, I restate: an initiator may not know if two
Portals
belong to the same Network Entity. For the purposes of discovery, all it
requires prior to establishing the discovery session is each Portal's
TCP
addressing information.

Without a priori knowledge of which portals are in the same Network
Entity,
it would be difficult for an initiator to deterministically know if
starting
a discovery session to Portal Y is going to reinstate its existing
discovery
session on Portal X.

Of the four possibilities you propose, I agree that II is on the path to
predictable behaviour. However, I suggest the decision to reinstate a
Discovery session should be based upon matching the tuple InitiatorName
+
ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals
may
carry four discovery sessions simultaneously from the one
InitiatorName+ISID
pair (one per Portal).

Thanks,
Ken 

Ken Sandars
Adaptec UK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mallikarjun C.
> Sent: 24 August 2005 21:04
> To: IPS
> Subject: [Ips] Discovery reinstatement
> 
> 
> I spent sometime studying previous email threads on this 
> topic and gave 
> the topic some thought.  My current thinking and rationale is written 
> below, I hope we'll arrive at a consensus on this topic this 
> time......
> 
> In short, I'm leaning towards not saying anything on discovery 
> reinstatement in the Implementer's guide, but still open to being 
> persuaded otherwise.  Sorry it's a long note.
> 
> [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. ]
> 
> 
> Question 1:
> Is it desirable that an initiator precisely know in advance when a new
> discovery session might reinstate an existing discovery session (with
> the same Network Entity)?
> 
> Yes (based on the plugfest feedback), so let's analyze what 
> this leads 
> us to.  If I got this wrong, feel free to reset me (especially to Bob 
> Russell).
> 
> If the answer is no, then the whole discussion is moot (jump 
> down to the
> conclusions).
> 
> Question 2:
> If so, how would the initiator deterministically know what reinstates
> what?
> 
> Option A:
> Assuming a fixed InitiatorName and ISID pair, a new no-named discovery
> session will reinstate an old no-named discovery session if the
> following is met:
> (1) servicing iSCSI Portal (for the new session) is hosted by the
>      same Network Entity as that of the existing session.
> 
> Option B:
> Assuming a fixed InitiatorName and ISID pair, a new no-named discovery
> session will reinstate an old no-named discovery session if the
> following are met:
> (1) servicing iSCSI Portal (for the new session) is hosted by the
>      same Network Entity as that of the existing session, and,
> 
> (2) TPGT of the servicing iSCSI Portal (for the new session) matches
>      that of the existing session.
> 
> Question 3:
> Can the conditions for each option be met?
> 
> Condition (1) can be met if we assume that the initiator has a
> (non-iSCSI) way of discovering that two IP addresses are hosted
> by one remote system (i.e. iSCSI Network Entity).
> 
> Condition (2) for realizing Option B however cannot be met 
> because TPGT
> is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the
> absence of a node name nor a way to communicate them to the initiator
> apriori.  Besides, there's a bootstrapping problem in that a discovery
> session is needed to find out TPGT associations.
> 
> So I believe condition (2) cannot be met, and thus do not see a way to
> support Option.B *given* the desire that the initiator 
> deterministically
> predict session reinstatement in advance (answer to Question.1).
> 
> 
> To summarize:
> 
> I see four possibilities (in decreasing order of my preference):
> 
> I.  We reject the assertion that initiator should be able to
>      deterministically predict session reinstatement.  So say
>      nothing about this topic in the Implementer's guide.
> 
> II. We accept the assertion.  So mandate Option A in Implementer's
>      guide.
> 
> III.We "semi-accept" the assertion by saying that the initiator cannot
>      predict reinstatement in advance but will know why a 
> reinstatement
>      happened post-fact (because the new session returned the 
> same TPGT
>      as did an existing no-named session).  So mandate Option B in
>      Implementer's guide.
> 
> IV. We reject the assertion.  Specify both Option A and 
> Option B in the
>      Implementer's guide.  And leave it to implementer's discretion.
> 
> I am personally fine with either I or II but not motivated to 
> go to III
> because it does not satisfy the "predict in advance" desire even
> while it requires enhancements/changes to RFC 3720 (and by 
> extension, to
> some existing implementations):
> a) allow a No-Name target node (i.e. a node that maps 1-to-1
>     with Network Entity)
> b) explicitly allow a TPGT numbering space for a No-Name target
> c) mandate returning TPGT on no-named discovery sessions.
> d) deal with second-order questions such as: shouldn't the
>     No-Name target information be returned in SendTargets response?
>     how about target port names for No-Name target node? ....
> 
> The net is that I see very little ROI in III.
> 
> I again see little ROI in IV.
> -- 
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

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

_______________________________________________
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: "John Hufferd" <[email-masked]>
Date: Fri, 2 Sep 2005 20:38:11 -0700

Again, I do not buy any of this.  

If the initiator wants to do a bunch of stuff in parallel, that seems
fine with me and it does not matter if the address are on the same
Network Entities, especially since the initiator can not tell.  But it
is very possible that an Initiator could have address for Portals on
lots of different Network Entities, and the address may be for portals
that cover several nodes (or address for different portals for the same
node) within the same Network Entity.  So it might be possible that an
initiator could want to do things in parallel.  (Yes they should use
iSNS, but ...)  So if you just ignore all this "keep the discovery
session like the regular session" stuff, there would be no problems, and
it works for all initiators. (And since we need to deal with inactive
discovery session anyway, nothing gets worse by ignoring all this
stuff.)

In all this communication, the only reason we are told that we need to
handle discovery and normal sessions in a like manner is that -- for
some implementation something is easer.  Well maybe, but I do not buy
it.

.
.
.
John L Hufferd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
William Studenmund
Sent: Friday, September 02, 2005 1:48 PM
To: Paul Koning
Cc: [email-masked]; [email-masked]
Subject: Re: [Ips] Discovery reinstatement

On Sep 2, 2005, at 11:11 AM, Paul Koning wrote:

>  Ken> Please consider the plight of the initiator which has been told
>  Ken> of four Portals to attempt discovery on. Has it broken any rule
>  Ken> when these are on separate Network Entities? I say no. What has
>  Ken> changed when these Portals turn out to be on the same Network
>  Ken> Entity?
>
> Good point.
>
>  Ken> All good implementers expect the unexpected, but it seems harsh
>  Ken> to make the unexpected reinstatement of a live discovery session
>  Ken> a normal working condition for the initiator. Especially when
>  Ken> its only 'crime' has been to attempt parallel discovery.

Ken, I have to wonder why we really need parallel discovery. I'm not 
saying we should disallow it. But if you really have enough targets 
that you want to do discovery in parallel, I think you should be using 
something like iSNS or SLP for discovery. :-)

> I agree.  I would say that reinstatement doesn't apply to discovery
> sessions.

Well, I disagree. We have the ISID rule which says when reinstatement 
applies, and it does not include session type in its description. So it 
does apply. And in some cases, I think it really helps. And it would be 
a real pain to make exceptions to it for discovery sessions.

Now, I don't mind if we play games with the rule for no-target-name 
sessions and let each portal be its own reinstatement domain (act as if 
each portal has its own TPGT value when performing ISID 
considerations). And I think we will end up with something that will 
make everyone happy. But the main thing is the ISID rule still applies, 
we just have the edge cases arranged such that folks will be unlikely 
to notice.

> Initiators shuldn't open multiple discovery sessions to teh same
> portal.  Targets that advertise multiple addresses should be prepared
> for simultaneous discovery sessions to each of them from the same
> target, and should simply treat those as independent.  That seems like
> the right answer given that, as you point out, the initiator can't
> prevent that (short of taking the inefficient approach of serializing
> everything).

If you mean "Targets that advertise multiple addresses should be 
prepared for simultaneous discovery sessions to each of them from the 
same _initiator_" then I agree (substituting in a SHOULD for should) 
assuming we are limiting this to no-target-name discovery. If you do 
discovery to a specific target, well, you need to respect its TPGT 
layout. :-)

Take care,

Bill