RE: iSCSI:eui64node

["John Hufferd" <hufferd@us.ibm.com>]

The biggest problem with the draft is that it does not state, in a way that
I could understand, what the problem is.  You state it was to ensure that
the WWNN was the same across the different Gateways, OK, but why.  What
does this give you that you would not have any way, that you think is
important.   Perhaps, there is a second level motivation that is not clear
to me.

You, also state, that the iSCSI Initiator would have two Nodes.  I think
you are mixing  FC terminology and iSCSI terminology here.  Lets review the
iSCSI Terminology, as follows:

 iSCSI Client Network Entity will almost always contain a single iSCSI
Initiator Node.  And it has one name, the iSCSI Initiator Node Name
(InitiatorName=......)  There may be Multiple dynamically created SCSI
Initiator Ports (with "n" different portals), but each SCSI Initiator Port
will drive different sessions and have completely different  I-T Nexus.  A
specific SCSI Port can be identified, within an iSCSI Initiator Node, by
its 6 Byte ISID.

I think that most FC Cards have both their own WWNN and their OWN WWPN, and
they are considered to be the SCSI Port, and manage a FC "Session".  So, if
two different iSCSI Session are going through the Gateways and they are
given different WWNNs I do not see the problem.  I do not understand why
you would want them to be the same, and what operational difference you
think that would mean.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Robert Grant <Robert.Grant@mcdata.com>@ece.cmu.edu on 01/25/2002 07:17:16
AM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    RE: iSCSI:eui64node




Hello,

> This came up at the  last, IETF meeting, and most folks disagreed with
it.
> But I think it was  useful to get it put into a draft form where we could
> respond  completely. The Draft seems to confuse the NODE
> name with a physical  HBA ID.  And it is not obvious that there is a
complete
> understanding of Multiple Connections per Session as they  apply across
HBAs (Portals).

The  draft might go too far giving examples of HOW a node identifier could
be arrived  at - and leave the impression that these are the ONLY
methods.The example of using the MAC address does give the  impression that
the HBA should be the node - but then goes on to say that for  more
sophisticated implementations, the node could consist of multiple
HBAs/NICs. The point trying to be made was that providing a 64-bit node
identifier isn't an onerous task - but it did end up confusing  things.

But in  fact you touch upon a key point - that the NODE is quite different
from the HBA.  A single host with 2 HBAs should be able to present a single
NODE. There are  occasions, however, where it's desirable for a single host
with 2 HBAs to appear  as 2 NODEs.Which comes back to a main point of the
draft - that  the best place to determine what is and isn't a node is the
node itself. So -  for topologies using a gateway, having a gateway try to
determine this would be  bad.

> I think you were trying to make sure that the WWNN  was unique across the
> different Gateways, but since it includes a eui  that has a vendor ID,
you
> must be worried about Gateways from the same  vendor.

Actually, the draft was trying to make sure the  WWNN was the SAME across
different Gateways. The draft suggests the WWPN could  be unique across
different gateways - and doesn't suggest that there are issues  with the
WWPN. The vendor ID of the EUI64NN would be that of the NODE vendor
(HBA/driver/OS) - not of the Gateway(s).

>(which I also do not
> see as a problem  which others should worry about).   In any event I did
not
>  fully understand the problem, and the solution was even less clear.
>
> Anyway somehow you are trying to make iSCSI node name be a name of  an
> adapter, and we took many pains to absolutely avoid  that.
Agreed  - the iSCSI node should not necessarily be an adapter.

>
> I also did not understand in your  negotiation examples.

Yeah -  just like the example of "one could use the MAC address to make a
64-bit  identifier" led to some confusion, I think trying to pack too much
into the  negotiation example was confusing, too. The example kinda said
"the Initiator  offered 'abc', the gateway/target offer 'def', 'ghi' and
'jkl', the Initiator  rejected those and offered 'abc', the Gateway
accepted 'abc'". Should just give  a simple "Initiator says 'abc',
gateway/target accepts  'abc'".

>
> What you are asking for is  iSCSI  Initiators to have a 64bit name on top
of
> the 48 bit ISID and the long  REAL node name that can be 255 Bytes long.
> Just so some gateway does not  coordinate with its partner Gateway.

I  think having Gateways "coordinate" in a truly robust fashion is a lot
more  complicated than it sounds. Once you consider error scenarios, I'd
suggest its  not practical for large (with many Gateways) "5-nines or
greater" installations.

> That means  that either ALL HBAs and iSCSI Device Drivers must deal with
this
> total  name, just in case there is a non coordinating Gateway in the
middle
>  some where.

This  was a sub-text to the more complicated "negotiation example" - that
if an  HBA/driver DIDN'T support the EUI64NN key, things could still work
in many  configurations (configurations having no or a single Gateway) by
having the  Gateway offer an identifier. So - no, the draft states pretty
clearly that it  would be optional (for instance "an optional Operational
Key is added") and not  ALL HBAs would need to deal with this. If a vendor
wanted an HBA to work well in  an environment with multiple Gateways,
however, the use of iSNS or an EUI64NN  operational key is required.

>This does not seem like a good idea to  me.
Thanks  for the comments.

>
>                        John L. Hufferd

Regards,
Rob

Rob Grant
McDATA  Corporation