Subject: RE: iSCSI:eui64node

From: Robert Grant <[email-masked]>
Date: Fri, 25 Jan 2002 10:17:16 -0500

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