Subject: Re: target discovery issue

From: Sandeep Joshi <[email-masked]>
Date: Wed, 18 Apr 2001 14:21:34 -0400

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
> 
> [email-masked] wrote:
> >
> > Sandeep,
> >
> > I think we are deep in T10 territory - this is a SCSI issue.
> >
> > Julo
> >
> > Sandeep Joshi <[email-masked]> on 18/04/2001 16:21:06
> >
> > Please respond to Sandeep Joshi <[email-masked]>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
> > 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 <[email-masked]> 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.
> > >

---

From: Mark Bakke <[email-masked]>
Date: Thu, 19 Apr 2001 13:32:03 -0500

(This is a re-send of another message about my wanting to
have an async event.  My apologies to those who have received
it twice).

The background is that Ralph mentioned that from an
architectural point-of-view, targets are not supposed to
know about each other, and that the out-of-band discovery
method should really be used instead.

That's technically correct; given that, we should probably
not send such an event on a connection to a specific target.
That leaves the canonical target connection as the "discovery
port", that could send events about other targets.  Since the
canonical target is an iSCSI-level thing, rather than SCSI-level
thing, there's nothing layer-violating about it.

I agree that in an iSNS-managed environment, that iSNS' event
mechanism is the way to do this, and this event would not be
needed.  The same MAY be true for an SLP environment, depending
on where we end up with the proposed notification mechanism
from RFC 3082.  I'm not completely sure yet on that one.

That leaves us with one particular environment where I am
concerned our discovery methods don't completely cover:

  Let's say that a pair of iSCSI gateways connect Storage
  Service Provider A with Customer B.  The gateways are
  configured with each other's IP addresses; and may run
  over a private connection or secured tunnel.  In this
  case, the Customer does not need to discover targets at
  *new* addresses; it just needs to discovery additional
  targets created behind the SSP's gateway.  If the customer
  gateway keeps a connection open to the SSP gateway's
  canonical target, it could receive notifications of new
  targets behind the gateway without having to deploy
  separate discovery protocols such as iSNS and SLP over
  this network.  It would make the tunneling model much
  easier in this case to keep it in-band. 

In the normal-case environment, where there are a bunch of
initiators wanting to discover a bunch of targets, it would
be better to use SLP or iSNS to do this.  They could even
be used to do this in the gateway-to-gateway case.  However,
I don't think that running separate, out-of-band discovery
protocols in this environment will be happily accepted by
the end customers, who would rather deal with fewer protocols
to firewall and tunnel.

At that rate, we could just say that the event is sent ONLY
on connections to the canonical target; initiators using the
other methods of discovery would not have to keep a canonical
target connection open for this, and would not have to implement
support for the event.  Targets could support sending the
event only if it was felt worthwhile, such as in a gateway
implementation.

This could also be done as a vendor-unique event, but there
is no defined way for a vendor to add async event messages
in iSCSI, and it would be better to just define the event and
have it used only where necessary.  We can update the description
of the event to make its use more clear.

Does that work better?

--
Mark

Ralph Weber wrote:
> 
> Gentlemen,
> 
> Target discovery is not covered in SAM so this area
> is one where I have no official standing.  That said,
> I will till my oar in just this once.
> 
> I have more than a little difficulty seeing how
> one iSCSI portal can usefully notify logged in
> initiators of new targets appearing.  The new
> targets the initiator cares about could easily
> be coming available through an iSCSI portal
> here the initiator has not yet logged in.
> 
> If the iSCSI portal is to notify an entity of
> new target creation, it seems to me that the
> entity notified should be the iSNS server.
> Then initiators that want to be notified of
> new targets would register for such notifications
> with the iSNS server, who would be the
> clearinghouse for such activities.
> 
> Just my $0.02.
> 
> Thanks.
> 
> Ralph...

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054