[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI:eui64node

    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:
    Robert Grant <> on 01/25/2002 07:17:16
    Sent by:
    Subject:    RE: iSCSI:eui64node
    > This came up at the  last, IETF meeting, and most folks disagreed with
    > 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
    > 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,
    > 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
    >  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
    > 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
    > total  name, just in case there is a non coordinating Gateway in the
    >  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
    Rob Grant
    McDATA  Corporation


Last updated: Fri Jan 25 14:17:55 2002
8482 messages in chronological order