Re: iSCSI: target discovery issue

[Mark Bakke <mbakke@cisco.com>]

Sandeep-

The reason I had wanted the iSCSI-level message on the canonical
target connection was to allow the use of in-band discovery for
a gateway-to-gateway connection.  You are right; in most cases,
iSNS or SLP will be there, but in the gateway-to-gateway
configuration, it is not usually desirable to have to tunnel
additional protocols through firewalls and tunneling devices.

How about if we change the statement to a MAY instead of a MUST
(only gateways would implement it, and initiators can ignore it)?
I could add to the description to say that it need not be implemented
on the actual hosts and devices themselves, which should use
one of the other mechanisms.

I really would like to use an async event to do this in-band, and
iSCSI provides no method to do vendor-unique async events.

--
Mark


Sandeep Joshi wrote:
> 
> Josh & John,
> 
> Thanks for the hi-level perspective.  I do agree that iSNS
> and/or SLP will do the trick here and that this functionality
> falls into the OA&M domain.
> 
> Four score and seven days ago (..approx!), this thread started due
> to confusion with the following line in the naming and discovery
> draft, which had no equivalent message code defined in the iSCSI
> Async PDU.
> 
> > 1) Section 4.2 last line before Section 4.2.1
> >    "the target MUST send any iSCSI-level async on the canonical
> >    session, to allow the initiator to discover new targets as
> >    they are created.."
> 
> Can the issue be laid to rest by removing this statement ?
> 
> Thanks,
> -Sandeep
> 
> > John, Sandeep,
> >
> > I would like to append to Mark's note that method D is
> > the iSNS.  The iSNS breaks from the device-by-device
> > management paradigm that the previous methods use.  It
> > provides for network-wide storage device discovery,
> > zoning and management.
> >
> > The details of how iSNS works is documented in the
> > iSNS document, and an overview is in the iSCSI N&D
> > requirements document.  But the key concept is that
> > instead of going to device A, configure its access
> > list, then on to device B, configure its access list,
> > then on to initiator A, configure its list of targets,
> > etc....you instead go to a single entity, the iSNS
> > server, to gain a network-wide view of all storage
> > assets.  If all storage devices have slaved their
> > discovery and management functions to the iSNS server,
> > then the iSNS is a single management point that the
> > GUI can use to configure discovery and access privileges
> > for the entire storage network.
> >
> > When a new target shows up on the network, it registers
> > in the iSNS.  The iSNS server then sends notifications to
> > interested iSNS clients (only those configured for this
> > notification with the proper zoning) informing them of the
> > new device. The iSNS client is a co-resident application
> > on iSCSI targets and initiators that maintains communication
> > with the iSNS server.
> >
> > Hope this helps.
> >
> > Josh
> >
> > > -----Original Message-----
> > > From: John Hufferd [mailto:hufferd@us.ibm.com]
> > > Sent: Wednesday, April 18, 2001 3:08 PM
> > > To: Sandeep Joshi
> > > Cc: ips@ece.cmu.edu
> > > Subject: iSCSI: target discovery issue
> > >
> > >
> > >
> > > First off you need to understand that we are talking about
> > > Targets, NOT LUs
> > > nor LUNs.
> > >
> > > Next this is a feature that you want to have in your
> > > management SW, and I
> > > believe that iSNS can help here. Josh Tseng pipe in here.
> > >
> > > Further, storage events don't usually just happen that
> > > everyone needs to
> > > know about it.  As a rule, storage is brought on to meet some
> > > requirement.
> > > The requirement is usually needed by a specific host.  Just
> > > because you add
> > > a Storage Controller does NOT mean that all the various host
> > > should start
> > > using the storage.  The storage is first established as LUs
> > > and the LUs are
> > > assigned to specific authorized Host (or iSCSI Nodes as we
> > > are calling them
> > > now) and when the session is started, and authenticated, that Host can
> > > issue the Report LUNs and that maybe the first time an LU has
> > > been given a
> > > Number for that particular Host.   But none of that should
> > > begin until the
> > > Host is sure that there is something for it to find.  And the thing it
> > > wants to find is a LUN not a SCSI Device/iSCSI Node or
> > > Target.  Getting
> > > knowledge of a new LU that can be used by a specific host is
> > > NOT an iSCSI
> > > thing.  It is SCSI, and very deep into the Management SW and Admin
> > > Processes.
> > >
> > > I punished you with this information so that you can see why I did not
> > > understand why you were concerned about a Host being
> > > automatically told
> > > about a new SCSI Device/ iSCSI Node/Target.  I would expect
> > > that if the
> > > administrator had gone to the work to bring in the storage controller,
> > > configure it for specific Hosts to use, set up the various LUs to be
> > > authorized for the various Hosts.  It seems reasonable for
> > > the Admin to ask
> > > the Host to recycle its discovery functions.
> > > .
> > > .
> > > .
> > > John L. Hufferd
> > > Senior Technical Staff Member (STSM)
> > > IBM/SSG San Jose Ca
> > > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > > Internet address: hufferd@us.ibm.com
> > >
> > >
> > > Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu
> > > on 04/18/2001
> > > 11:21:34 AM
> > >
> > > Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > > To:   ips@ece.cmu.edu
> > > cc:
> > > Subject:  Re: target discovery issue
> > >
> > >
> > >
> > >
> > > just realized that the reflector is not seeing this discussion.
> > > the question at hand is how should target discovery notification
> > > be sent in the iSCSI world.
> > >
> > > Mark Bakke wrote:
> > > >
> > > > Actually, I think that part of it is an iSCSI issue.  That is,
> > > > if a new target is created, that's at the SCSI level.  But if I
> > > > add an iSCSI address on which to access that target, it now must
> > > > be discovered first by the iSCSI layer on the host, before it
> > > > can be presented to the SCSI layer.  In this case, we would need
> > > > to send an iSCSI event indicating that there is a new target (or
> > > > at least that there is some change in availability of targets);
> > > > the host would then use SendTargets to find out the specifics.
> > > >
> > > > This brings up Sandeep's question #2.  If I am a target, I can
> > > > send this message either:
> > > >
> > > >  a) On every iSCSI connection
> > > >
> > > >   OR
> > > >
> > > >  b) On all connections to canonical targets
> > > >
> > > > Method a gives us better coverage, and does not require an
> > > > initiator to keep its canonical target connection around in
> > > > between these little sendtargets commands.  However, if an
> > > > initiator logs into a canonical target, finds that it has no
> > > > targets to connect to (yet), and one is added later, the
> > > > initiator would only find out if it had kept its canonical
> > > > target connection, unless it is using an out-of-band discovery
> > > > mechanism.
> > > >
> > > > Method a will also tend to bother connections to targets
> > > > that are doing the "real" work (data path stuff).
> > > >
> > > > Method b will keep these events away from the data path, and
> > > > will not generally have to send so many events.  However, it
> > > > would require each initiator that wanted to be notified to keep
> > > > its canonical connection around.
> > > >
> > > > There is a Method C, which is a combination of the above:
> > > >
> > > >  c) The device will send this async event message on ONE of the
> > > >     connections to each initiator name (formerly WWUI) that is
> > > >     connected to it.  If one of these connections is to the
> > > >     canonical target, the device will use that one.
> > > >
> > > > Method c allows the initiator to choose whether it would rather
> > > > keep an explicit canonical target connection around (e.g. if the
> > > > other connections have been pushed down to hardware), or whether
> > > > it would rather not keep the connection around, and be notified
> > > > on one of the others.  The number of messages sent by targets
> > > > would be identical to that in method b.
> > > >
> > > > --
> > > > Mark
> > > >
> > > > julian_satran@il.ibm.com wrote:
> > > > >
> > > > > Sandeep,
> > > > >
> > > > > I think we are deep in T10 territory - this is a SCSI issue.
> > > > >
> > > > > Julo
> > > > >
> > > > > Sandeep Joshi <sandeepj@research.bell-labs.com> on
> > > 18/04/2001 16:21:06
> > > > >
> > > > > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> > > > >
> > > > > To:   Julian Satran/Haifa/IBM@IBMIL, mbakke@cisco.com
> > > > > cc:
> > > > > Subject:  target discovery issue
> > > > >
> > > > > Julian & Mark,
> > > > >
> > > > > Friendly reminder... the issue mentioned below may not
> > > > > have been resolved.
> > > > >
> > > > > 1) Is target discovery going to be the SCSI event or will
> > > > >    it be wrapped up as an iSCSI event ?
> > > > > 2) Do we have to keep a session to the canonical target
> > > > >    always open to be able to do target discovery?
> > > > >
> > > > > -Sandeep
> > > > >
> > > > > I am not sure.  There are some SCSI items in it too (SCSI
> > > handles now
> > > the
> > > > > appearnce of new LUs).
> > > > >
> > > > > I will need a longer discussion with NDT to understand
> > > the semantics.
> > > > >
> > > > > Julo
> > > > >
> > > > > Sandeep Joshi <sandeepj@research.bell-labs.com> on
> > > 12/03/2001 22:25:27
> > > > >
> > > > > Julian,
> > > > >
> > > > > in case you skip this one..
> > > > > your response is required on point (1) for amending iSCSI draft.
> > > > >
> > > > > -sandeep
> > > > >
> > > > > Sandeep-
> > > > >
> > > > > The problem you pointed out in item number 1 creates the need
> > > > > for an additional iSCSI-level event.  Since the discovery of
> > > > > targets happens at the iSCSI level, rather than at the SCSI
> > > > > level, how about adding this to 2.18.1 (in iSCSI-05)?
> > > > >
> > > > >   4   Network entity indicates that a "target discovery" event
> > > > >       has occurred.
> > > > >
> > > > > Upon receiving this message, the initiator should use SendTargets,
> > > > > or whatever other methods of discovery it is using, to find out
> > > > > what has changed.  Usually, this would be due to adding a new
> > > > > target.
> > > > >
> > > > > We will fix items 2-4; thanks for pointing them out.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mark
> > > > >
> > > > > Sandeep Joshi wrote:
> > > > > >
> > > > > > 1) Section 4.2 last line before Section 4.2.1
> > > > > >     "target MUST send any iSCSI-level async on this session,
> > > > > >      allowing the initiator to discover new targets.."
> > > > > >
> > > > > >    The session mentioned here is a session to the
> > > canonical target.
> > > > > >
> > > > > >    However, the iSCSI 05 draft does not mention any
> > > such condition
> > > > > >    in Sec 2.18 on Async Message.   In there, a SCSI
> > > event (note: not
> > > > > >    iSCSI) is used to notify availability of new targets.
> > > > > >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054