Re: target discovery issue

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

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.
> > >