Subject: [Ips] iSCSI MIB compliance with iSCSI draft 20

From: "Michele Hallak - Stamler" <[email-masked]>
Date: Wed, 4 Feb 2004 14:17:43 +0200

Hello,
Working on an implementation of the iSCSI MIB, we encountered the following problems:
1. Minor Issue: What is the meaning of Initiator Portal Tag? It seems that it's there for historical reason. If confirmed, the object: iscsiIntrPortalTag and therefore the all table: iscsiIntrPortalAttributesTable should be removed.
2. Target Portal Group Tag: The scope of the tag is per target device (node) and not per iSCSI instance. The actual MIB allows to define several target portals whithin one entity without any relation to the target device node. 
Therefore, if I want to define a portal (IP address + TCP Port) with a tag "x" (for one target device) and with a tag "y" (for a different target device), I have to set two identical rows with just the object "tag" different.(And no direct connection between the portal and the target node device, just via the SCSI target port name of the SCSI MIB). It is generally not the usage.
I suggest to add an index  to the portal table. This index will be:
- "0" for all nodes within the iSCSI instance.
or
- the index of the node (preceding the index of the portal). So, all the portals depending on one node will be nicely organized whithin an iSCSI instance.

I'll be very glad to get any clarifications concerning those two issues.

Michele

Visit the SANRAD Live Demo of a complete IP Based SAN and Virtualization Solution at CeBIT 2004 (Hannover, Germany 16-24 March, 2004), at the eSeSIX stand, in Hall 6, Stand G36 
SANRAD - access, share, manage
=================================
Tel: +972 (3) 767 4809
Fax: +972 (3) 647 4104
E-mail: [email-masked] <mailto:[email-masked]> 
Web: www.sanrad.com <http://www.sanrad.com/> 
Address: 32 Habarzel St. Tel-Aviv 69710, Israel

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

---

From: [email-masked]
Date: Wed, 4 Feb 2004 20:47:35 -0800 (PST)

> 1. Minor Issue: What is the meaning of Initiator Portal Tag? It seems
> that it's there for historical reason. If confirmed, the object:
> iscsiIntrPortalTag and therefore the all table:
> iscsiIntrPortalAttributesTable should be removed.

I don't think so. While the initiator portal tag does not have the same
protocol significance that TPGT has, it's useful in that it can indicate
which initiator ports can participate in multi-connection sessions. iSCSI
sessions can't span initiator portals with differing IPTs.

I agree that initiator software has to respect the IPT concept; iSCSI
won't really care about it and if all the connections have the same
initiator name and ISID, the session will span all of them. If the
initiators behind the different portals can't share a session yet are all
logged into the same target portal group, things will get messy.

> 2. Target Portal Group Tag: The scope of the tag is per target device
> (node) and not per iSCSI instance. The actual MIB allows to define
> several target portals whithin one entity without any relation to the
> target device node.

> Therefore, if I want to define a portal (IP address + TCP Port) with a
> tag "x" (for one target device) and with a tag "y" (for a different
> target device), I have to set two identical rows with just the object
> "tag" different.(And no direct connection between the portal and the
> target node device, just via the SCSI target port name of the SCSI MIB).
> It is generally not the usage.

Right now, if you use the MIB, you really can't have different TPGTs for a
portal. I think your work-around will really confuse some clients. I agree
it should be different.

> - the index of the node (preceding the index of the portal). So, all the
> portals depending on one node will be nicely organized whithin an iSCSI
> instance.

I think it would be better to have a table that ties nodes to portals with
an explicit portal tag. Like how iSNS does it.