Re: iSCSI: Representing iSCSI devices on FC fabrics

[Thanu Skariah <tskariah@npd.hcltech.com>]

I see the disconnect now. We have designed the gateway to represent
each FC node as an iSCSI end point, not the gateway.  This way multiple
gateways only represent multiple paths to the same iSCSI node. Hope this
answers the other points you have raised below.

Thanks,
Thanu

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> > Are you suggesting that two gateways should *not*  present the same
> > iSCSI name for a given FC node ? I thought they should present the same
> > iSCSI name and different iSCSI addresses (since it maps the path to
> > the target) for any given FC node.
> 
> I was attempting to very explicitly state that two iSCSI gateways should
> !NOT! present the *same* iSCSI name for a given FC node!!
> 
> I see how you may have formed this conclusion and this area needs to be
> clarified in the Naming and Discovery document.
> 
> It's the gateway device that really needs to be the named iSCSI node,
> because it's not as simple as a "proxy passthru".  The gateway device itself
> contains all kinds of iSCSI configuration and state that (I'm assuming) is
> not shared with another iSCSI gateway that might present the same name in
> the EUI naming scheme you outlined.  The "iSCSI Node" that must have the
> unique name is the iSCSI gateway, not the FC device it is proxying for.  For
> instance, one gateway will (should) have an access control list for iSCSI
> authentication of initiators or targets.  A separate gateway using the
> naming scheme you outlined will not share this information, so for all
> practical purposes, it is *not* the same iSCSI device, even though it may
> represent the same FC devices as another gateway.
> 
> In addition (and more importantly), there are rules the iSCSI
> target/initiator nodes must follow in order to assure there is "no parallel
> nexus" for SCSI (ISID assignment and target portal group representation -
> see section 2.5.2, 2.5.3 of iSCSI draft 09).  In order to correctly follow
> those rules, separate gateways exporting duplicate iSCSI names for FC
> devices would have to share real-time state information between boxes.
> While that may be part of your design, I'm sure it's not part of competing
> gateway vendors designs to share this information cross-vendor :-)
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
> 
> > -----Original Message-----
> > From: Thanu Skariah [mailto:tskariah@npd.hcltech.com]
> > Sent: Tuesday, November 20, 2001 5:57 AM
> > To: KRUEGER,MARJORIE (HP-Roseville,ex1)
> > Subject: Re: iSCSI: Representing iSCSI devices on FC fabrics
> >
> >
> > Hi,
> >
> >         Are you suggesting that two gateways should *not*  present the
> same
> > iSCSI name for a given FC node ? I thought they should present the same
> > iSCSI name and different iSCSI addresses (since it maps the path to
> > the target) for any given FC node.
> >
> >    The iSCSI spec only seems to mandate that the node name is permanent
> > and if every gateway were to use the same format (eui in this case), the
> > same end
> > device (node) is always represented the same way. But yes, nothing forces
> a
> > gateway to represent it using this format.
> >
> >
> >   Also, consider the following from the iSCSI Naming and
> > Discovery draft
> > Sec2.1 :
> >
> > 5. iSCSI names must support integration with existing unique naming
> >        schemes.
> >
> > Again, check the portion in my original mail that quotes the same
> > draft. It talks of a gateway "representing" an FC device, not owning.
> > I thought this would be sufficient rules for a gateway naming scheme.
> >
> > If it isn't we may need to incorporate text along the lines suggested
> > by Robert Snively into the naming draft.
> >
> > Thanks,
> > Thanu
> >
> >
> > "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> > >
> > > This use of the eui. naming format will ONLY be acceptable
> > if the iSCSI
> > > gateway device is the only iSCSI gateway device in the
> > world that is allowed
> > > to "represent" these FC devices - can your implementation
> > guarantee that?
> > > Another iSCSI gateway on the same FC fabric (another of
> > your gateways?)
> > > might also use that naming convention (as Jim H points out)
> > and that would
> > > violate the requirements of iSCSI naming.
> > >
> > > The eui. naming format was intended for use when the iSCSI
> > device "owns" the
> > > EUI number (as those FC devices "own" their WWN).  This
> > gateway usage is not
> > > what was intended.
> > >
> > > Marjorie Krueger
> > > Networked Storage Architecture
> > > Networked Storage Solutions Org.
> > > Hewlett-Packard
> > > tel: +1 916 785 2656
> > > fax: +1 916 785 0391
> > > email: marjorie_krueger@hp.com
> > >
> > > > -----Original Message-----
> > > > From: Thanu Skariah [mailto:tskariah@npd.hcltech.com]
> > > > Sent: Thursday, November 15, 2001 11:12 PM
> > > > To: Robert Grant
> > > > Cc: 'ips@ece.cmu.edu'
> > > > Subject: Re: iSCSI: Representing iSCSI devices on FC fabrics
> > > >
> > > >
> > > > Robert,
> > > >
> > > >
> > > >     iSCSI allows different naming formats, of which one
> > > > format is the EUI
> > > > format  (See the example
> > > > in sec 2.2 .7 and the naming draft -
> > > > http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-
> > > > disc-02.txt )
> > > >
> > > >     The EUI representation  is of the form eui . <WWN>.  Each
> > > > FC device's
> > > > WWName
> > > > can be used to form the corresponding iSCSI name for the
> > > > device.  This is what
> > > > we are
> > > > doing on a linux based software FCP/iSCSI gateway that we are
> > > > implementing, and
> > > > this
> > > > is why :
> > > >
> > > > (From the naming and discovery draft ):
> > > >
> > > > BeginQuote "
> > > >
> > > > Type "eui." (IEEE EUI format)
> > > >
> > > >    The IEEE iSCSI name might be used when a manufacturer
> > is already
> > > >    basing unique identifiers on World-Wide Names as defined
> > > > in the SCSI
> > > >    SPC-2 specification.
> > > >
> > > >    It may also be used by a gateway representing a Fibre
> > Channel or
> > > >    SCSI device that is already adequately identified using a
> > > > world-wide
> > > >    name.
> > > >
> > > > " End Quote
> > > >
> > > >
> > > > Thanks,
> > > > Thanu
> > > >
> > > >
> > > >
> > > > Robert Grant wrote:
> > > >
> > > > >                         Hello all,
> > > > >
> > > > >                         I have a question on the
> > > > representation of iSCSI
> > > > > devices into Fibre Channel fabrics for an iSCSI-to-FC
> > > > "gateway" device and
> > > > > would like to solicit people's thoughts on how best to do
> > > > this. A gateway
> > > > > device will allow iSCSI devices and FCP devices to access
> > > > each other, but in
> > > > > order to do this a consistent representation of the devices
> > > > is needed. I
> > > > > haven't been able to reconcile the iSCSI and FCP standards
> > > > using what's
> > > > > currently in the iSCSI standard, and wanted to see if there
> > > > was any support
> > > > > to expanding the iSCSI standard to address this (a standard
> > > > solution is, of
> > > > > course, much more preferred to every gateway vendor doing
> > > > it in their own
> > > > > proprietary way). In particular, how would an iSCSI device
> > > > map onto Fibre
> > > > > Channel's World Wide Name (WWN)? Would every device have
> > > > its own WWN, or
> > > > > could many iSCSI devices use a single WWN? There have been
> > > > some discussions
> > > > > (for example, there was even discussion of including a WWN
> > > > field in the
> > > > > iSCSI Login for a Gateway to proxy with in
> > > > >
> > >
> > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg01616.html),
> > but what is the
> > > > current view?
> > > >
> > > >                         A first approach might be that
> > many iSCSI devices
> > > > could use a single WWN. This can work well for FC-AL
> > devices "directly
> > > > attached " to the IP network or for small FC fabrics -
> > and where the
> > > > predominant interconnect and management of that
> > interconnect is the IP
> > > > network.
> > > >
> > > >                         This approach views the FC fabric
> > as flat (or at
> > > > least perhaps that FC zoning is "turned off"). As the FC
> > fabric gets
> > > bigger,
> > > > though, this first approach can create two layers of
> > management - one must
> > > > first configure the FC network and then configure the IP
> > network (since
> > > the
> > > > individual iSCSI devices sharing a single WWN can only be
> > zoned as a
> > > group).
> > > > The two layers are first "this group of iSCSI devices can
> > access this
> > > zone"
> > > > on the FC side and then "this iSCSI device can access
> > this FC device in
> > > this
> > > > zone" on the iSCSI side. If there was a clean integration
> > with FC zoning
> > > > (and associated management of the FC zoning), this may be avoided.
> > > >
> > > >                         A further complication is that,
> > as the FC fabric
> > > > gets even bigger, a single iSCSI device could end up with
> > multiple entry
> > > > points (i.e. paths through multiple gateways) into a
> > single FC fabric. Is
> > > > there any common way to represent iSCSI devices (for
> > instance, with
> > > respect
> > > > to WWNs) that allows the unique identification of that
> > iSCSI device - even
> > > > though there are multiple entrypoints onto the FC fabric?
> > The case of
> > > > multiple gateways (possibly from different vendors) is
> > the clearest
> > > example
> > > > of the need for a standard.
> > > >
> > > >                         Thank you for your time and I
> > look forward to all
> > > > comments/suggestions.
> > > >
> > > > Regards,
> > > > Rob
> > > >
> > > > Rob Grant
> > > > McDATA Corporation
> >