RE: iSCSI: "conservative reuse" requirement

[Black_David@emc.com]

> >Once that's done, what's the value in permitting operating modes
> > other than "conservative reuse"?
> 
> I thought we already discussed this - that of two initiator NICs
> each establishing a session (acting as independent initiator ports)
> to a different target portal group.

That's actually the same "operating mode" as far as I'm concerned -
one assigns a separate ISID to each NIC, and then some sort of
configuration restriction prevents each NIC from talking to both
Target Portal Groups (i.e., if one of the NICs could talk to
both Target Portal Groups, it would use the same ISID(s) for
its session(s) to both TPGs).  One NIC with one session to each
of two different Target Portal Groups really ought to be using
the same ISID for each session.  

> > - SHOULD use "conservative reuse" in setting up sessions
> 
> I guess this is okay, the other alternative/complement is wording 
> (proposed earlier in this thread) that focuses on where conservative 
> reuse is a MUST.

I think a complementary "MUST implement" and "SHOULD use" are needed:
- MUST implement "conservative reuse" of ISIDs in a fashion that
	doesn't require session teardown.  In the above example,
	it would be wrong to have to reset one of the NICs in
	order to get it to use the same ISID to talk to both
	Target Portal Groups.
- SHOULD use "conservative reuse" of ISIDs in setting up sessions
	(i.e., in the absence of some sort of configuration setting
	that forces "conservative reuse").  
The MUST is needed to avoid the "two operating modes" problem.
The SHOULD is to encourage persistent shared reserves to
"just work" without annoying additional configuration fiddling,
and may need an additional MUST to force "conservative reuse".

It would be simpler to make "conservative reuse" a "MUST use", but
I've heard objections to that ... so the above is what the alternative
appears to look like.

> 
> > - SHOULD use "conservative reuse" in setting up sessions from the same
> >         Initiator Portal Group (set of IP addresses) to different Target
> >         Portal Groups
> 
> In the sense you used "initiator portal group" here, it ought
> to be defined (otherwise, simply use "initiator node" in your sentence)
> as "the set of initiator portals sharing the same ISID Type & ISID
> Naming Authority values and sharing one ISID Qualifier name space,
> and that allow a session to span an arbitrary subset of the portals."

That sounds about right, thanks.
 
> IOW, if two NICs A and B from the same vendor (so same Type and Naming 
> Authority) are present in a host (so share the ISID Qualifier space,
> perhaps with a s/w "ISID allocator" in the host or whatever), but can
> not span a session across them, then they are technically two independent
> "initiator portal groups".

Yes, that specific example is definitely ok.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------