RE: iSCSI:eui64node

[Robert Grant <Robert.Grant@mcdata.com>]

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