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

From: "Galloway, Bill" <[email-masked]>
Date: Sun, 31 Jul 2005 23:13:40 -0500

Julian,
 
I can accept that TPGT was not intended to be a target port-id by
itself.  However I am not aware of anything that says that multiple
targets cannot share a TPGT.  Am I missing something?
 
Bill Galloway

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julian Satran
	Sent: Sunday, July 31, 2005 1:30 PM
	To: Mallikarjun C.
	Cc: IPS; [email-masked]
	Subject: Re: [Ips] Re: ISID and DiscoveryRe:
draft-ietf-ips-iscsi-impl-guide-00.txt

	Mallikarjun, 
	
	Option A was the one considered when iSCSI was written. Bill is
talking about an implementation in which TPGT is an entity by its own
used by several targets. 
	His parallel with the target port-id illustrates this point.
TPGT however was not intended to be a target port-id by itself. 
	
	Regards, 
	Julo 

"Mallikarjun C." <[email-masked]> 
Sent by: [email-masked] 

30-07-05 04:01 

To
IPS <[email-masked]> 
cc
Subject
Re: [Ips] Re: ISID and Discovery Re:
draft-ietf-ips-iscsi-impl-guide-00.txt

	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.
	
	Mallikarjun
	
	Mallikarjun Chadalapaka
	Networked Storage Architecture
	StorageWorks Division
	Hewlett-Packard MS 5668
	Roseville CA 95747
	cbm [at] rose.hp.com

	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.
	
	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).
	
	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.

	
	
	_______________________________________________
	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, 1 Aug 2005 10:57:56 +0200

Bill,

TPGT is just a value. If by sharing you mean an implementation may use 
internally TPGT to indicate the same physical set of ports that is 
perfectly legitimate however the standard does no require that and does 
not attach any meaning to the TPGT beyond the 
combinationofTarget-Name+TPGT.

If you are looking to standardize this type of  behavior RFC3720 is the 
probably not the right place as TPGT has no role on the wire by itself 
(only in combination with a target name) although that may be a decent 
practice. You might want to look to SNIA that attempts to standardize 
adapter management in their IPS working group and may consider this type 
of behavior in implementations compatible with their management interfaces 
(that is why I am copying them).

Julo

"Galloway, Bill" <[email-masked]> 
Sent by: [email-masked]
01-08-05 06:13

To
<[email-masked]>
cc

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

Julian,
 
I can accept that TPGT was not intended to be a target port-id by itself. 
However I am not aware of anything that says that multiple targets cannot 
share a TPGT.  Am I missing something?
 
Bill Galloway

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Julian Satran

Mallikarjun, 

Option A was the one considered when iSCSI was written. Bill is talking 
about an implementation in which TPGT is an entity by its own used by 
several targets. 
His parallel with the target port-id illustrates this point. TPGT however 
was not intended to be a target port-id by itself. 

Regards, 
Julo 

To
IPS <[email-masked]> 
cc

Subject

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.

Mallikarjun

Mallikarjun Chadalapaka

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.

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).

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.