SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: target discovery issue



    (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
    mbakke@cisco.com
    763.398.1054
    


Home

Last updated: Tue Sep 04 01:04:58 2001
6315 messages in chronological order