Subject: RE: [Ips] Portal group discovery

From: "Dan Bar Dov" <[email-masked]>
Date: Sun, 8 Oct 2006 19:28:58 +0200

I guess my confusion with portal group is fully understanding the way it is 
supposed to be used.
 
When a portal group is used for multiple connections in session, 
the cmnSN must be monotonic and shared among all the ports- 
so this indeed is a shared state, and it cannot work with multiple routers.
 
However, if all I want to achieve is multipath fail-over, I can have multiple sessions,
or MCS - but with only one session active. In both cases, the initiator can use an
alternative session or connection, and the cmdSN will advance just fine.
 
>From all the answers, I understand now that portals are indeed for MCS, and failover
using multiple devices such as routers, needs to use multiple sessions (active+standby), 
and that distinct devices, even providing the same service - access to same "real target", 
should not, and must not be part of the same portal group.
 
Dan

________________________________

	From: Julian Satran [mailto:[email-masked]] 
	Sent: Wednesday, October 04, 2006 9:04 PM
	To: Dan Bar Dov
	Cc: [email-masked]; John Hufferd; William Studenmund
	Subject: RE: [Ips] Portal group discovery

	Dan, 
	
	The portal groups have to share more than a target name - they'll have to have some common state (the CmdSN etc.). 
	If behind the routers there is only the "real" FC target I don't see how you can build a portal out of several routers. If the target function is in the "real target" it might as well know who all its front-ends are. 
	
	Julo 

"Dan Bar Dov" <[email-masked]> 

03/10/06 12:00 

To
<[email-masked]> 
cc
"John Hufferd" <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL, "William Studenmund" <[email-masked]> 
Subject
RE: [Ips] Portal group discovery

	Let me try to explain how it can and does happen. 
	  
	Our iSCSI target device is a "gateway" (or router). It provides FC SAN 
	targets to iSCSI SAN. The iSCSI target name is generated from the FC WWNN. 
	  
	When there are more then one such routers in the iSCSI SAN, it is possible and normal 
	for two (or more) iSCSI routers to expose the same FC target. This is not by mistake, 
	rather, it allows fail-over between such routers, where the initiator uses the multiple portals 
	for failover. 
	  
	Given such a configuration, how does the initiator discover it? 
	option 1: the routers have "cluster awareness", one router can combine information from the whole 
	router cluster for sendTargets response. 
	option 2: the initiator is configured with multiple discovery addresses - one per router. 
	  
	If option 2 is used, then the initiator needs to combine information discovered in discrete sendTargets 
	responses and produce portal groups. 
	  
	My question relates specifically to that situation - it is not clear from the iSCSI spec, if such failover 
	between portals (with the same pgt) discovered in discrete sendTargets responses is allowed. 
	  
	Thanks, 
	Dan 

	
________________________________

	From: Julian Satran [mailto:[email-masked]] 
	Sent: Friday, September 29, 2006 8:05 AM
	To: William Studenmund
	Cc: Dan Bar Dov; [email-masked]
	Subject: Re: [Ips] Portal group discovery

	This is not supposed to happen (getting partial data in a session) 
	If it happens it can be the result of a reconfiguration (between the two discovery sessions). 
	
	Julo 

William Studenmund <[email-masked]> 

29/09/06 05:31 

To
Dan Bar Dov <[email-masked]> 
cc
[email-masked] 
Subject
Re: [Ips] Portal group discovery

	

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA1
	
	On Sep 28, 2006, at 7:59 AM, Dan Bar Dov wrote:
	
	> Is it allowed for an initiator to create a single portal group from  
	> information
	> collected from two (or more) sendTargets discovery sessions?
	
	I don't think you need two or more SendTargets discovery sessions.  
	You are supposed to hear about all portals in one SendTargets  
	response, so it's supposed to all be there.
	
	If you had very separate off-load cards, I could see that not being  
	followed. But then chances are you can't have a session span said  
	cards anyway. :-)
	
	Take care,
	
	Bill
	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1.4.1 (Darwin)
	
	iD8DBQFFHIV8DJT2Egh26K0RAtMRAJ0aABo+mr7HRWRf5ClX44sB15uSAACglrL7
	oBLBpnH9PMvBjyu4RS+9dcc=
	=3dI5
	-----END PGP SIGNATURE-----
	
	_______________________________________________
	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: Julian Satran <[email-masked]>
Date: Mon, 9 Oct 2006 09:12:27 +0200

Dan,

The question of failover was central to the design. However we had to 
consider waht is reasonable to achieve with the wire protocol and what 
not..
Obviously what you want can be achieve within the protocol within a single 
session. It requires however that the initiator and taget cooperate 
somewhow - e.g., do not send commands on other that the active path and 
your routers interpret the first command on a failover path as a 
"switching" command and take all the state from the new commands. That is 
definitely acceptable and can be achieved with many means (private keys, a 
hint in the new 'architecture key' etc..
If it is simple enough and interesting to the community you may want to 
follow the "architecture" key path and publish it.

Regards,
Julo

08/10/06 19:28

To
Julian Satran/Haifa/IBM@IBMIL
cc
<[email-masked]>, "John Hufferd" <[email-masked]>, "William 
Studenmund" <[email-masked]>
Subject
RE: [Ips] Portal group discovery

I guess my confusion with portal group is fully understanding the way it 
is 
supposed to be used.
 
When a portal group is used for multiple connections in session, 
the cmnSN must be monotonic and shared among all the ports- 
so this indeed is a shared state, and it cannot work with multiple 
routers.
 
However, if all I want to achieve is multipath fail-over, I can have 
multiple sessions,
or MCS - but with only one session active. In both cases, the initiator 
can use an
alternative session or connection, and the cmdSN will advance just fine.
 
>From all the answers, I understand now that portals are indeed for MCS, 
and failover
using multiple devices such as routers, needs to use multiple sessions 
(active+standby), 
and that distinct devices, even providing the same service - access to 
same "real target", 
should not, and must not be part of the same portal group.
 
Dan

Dan, 

The portal groups have to share more than a target name - they'll have to 
have some common state (the CmdSN etc.). 
If behind the routers there is only the "real" FC target I don't see how 
you can build a portal out of several routers. If the target function is 
in the "real target" it might as well know who all its front-ends are. 

Julo 

To
<[email-masked]> 
cc
"John Hufferd" <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL, 
"William Studenmund" <[email-masked]> 
Subject
RE: [Ips] Portal group discovery

When there are more then one such routers in the iSCSI SAN, it is possible 
and normal 
for two (or more) iSCSI routers to expose the same FC target. This is not 
by mistake, 
rather, it allows fail-over between such routers, where the initiator uses 
the multiple portals 
for failover. 
  
Given such a configuration, how does the initiator discover it? 
option 1: the routers have "cluster awareness", one router can combine 
information from the whole 
router cluster for sendTargets response. 
option 2: the initiator is configured with multiple discovery addresses - 
one per router. 
  
If option 2 is used, then the initiator needs to combine information 
discovered in discrete sendTargets 
responses and produce portal groups. 
  
My question relates specifically to that situation - it is not clear from 
the iSCSI spec, if such failover 
between portals (with the same pgt) discovered in discrete sendTargets 
responses is allowed. 
  
Thanks, 
Dan 

This is not supposed to happen (getting partial data in a session) 
If it happens it can be the result of a reconfiguration (between the two 
discovery sessions). 

Julo 

To

Take care,

Bill