SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Naming: WWUIs, URNs, and namespaces



    David,
    
    Thank you for your explanation.  As a small side note, the list I gave was a
    list of service related aliases.  I intended this to be a comprehensive list
    of all the typical services located in this manner.  The machine that is
    identified by an alias would use this for some other name assigned to allow
    reassignment.  Aliases are a convention to allow outsiders a likely means of
    locating services.  Mail, News, or WWW are perhaps the most common uses of
    this convention.  From what you are saying, iSNS would make sense as a
    conventional alias and not iSCSI.  One is likely to have a need to expose
    several such machines so a single service locator would not be appropriate
    for an iSCSI server.  You could think of this as just another service found
    by means of a convention.  In this case, it is a SCSI Name Service that
    should be found by an alias convention.
    
    I was trying to interpret the statement made by Mark Bakke at the origin of
    this thread-
      "So I take it that WWUIs are fine, as long as they use
      existing global name spaces" ...
    
      "OTOH, a storage service provider could
      provide its own names by using the reverse-DNS authority.
      Everyone has a DNS name.  This would enable the SSP to provide
      its customers with a WWUI that would not change if the back-end
      storage device was replaced.  After all, it's not the device
      that's important to this customer, it's the DATA."
    
    You saw my extrapolation of what changes were implied.  From your
    statements, I admit I do not understand the meaning of these statements as
    it does imply WWUI is used as a naming convention.  As we are discussing
    changes to existing specifications, you can understand why I am seeking
    guidance on the reflector.
    
    Doug
    
    >
    > > So from what I see from your example is iSCSI.Example.Com
    > returns the WWUI
    > > via SCSI that is then inserted into the domain to obtain the desired IP.
    >
    > No for a couple of reasons:
    > - The WWUI is not inserted into the domain.  The WWUI is an identifier,
    > 	not an address, and extracting its DNS portion and contacting that
    > 	host will not generally result in anything useful happening.
    > - The IP is the *same* as iscsi.example.com, because the Send Targets
    > 	command instructs whatever machine has been contacted to send
    > 	a list of targets that are exported from that machine.
    > Note that the machine contacted could be foo.example.com (it doesn't
    > have to be iscsi.example.com) as  the "iscsi" is the iSCSI target name
    > sent in the iSCSI login command - it's not part of the DNS hostname.
    >
    > > As example [WWUI].example.com which is not World Wide Unique
    > Identification but
    > > at least unique to example.com.  Why are you describing this process as
    > > reverse DNS?  If this is the process then I find the term reverse DNS
    > > confusing.
    >
    > Because the actual name returned would be something like
    > com.example.example7 - since the DNS components are reversed, the
    > naming authority is referred to as "reverse DNS".  Note that the name need
    > not contain the name of the machine returning them - com.example.example7
    > could be returned from iscsi.example.com, foo.example.com, or
    > bar.example.com, BUT if more than one of them returns it, it MUST be the
    > same target every time.  So, one could connect to foo.example.com, do
    > an iSCSI login to the "iscsi" target at foo.example.com, send it the
    > "Send Targets" command, and get back com.example.example1,
    > com.example.example2, etc.  All of these are separate targets
    > behind the same communication endpoint at foo.example.com.
    >
    > > You are referring to a conventional alias.
    >
    > No, it's not alias.  "iscsi" is a canonical target used by iSCSI -
    > none of the aliases listed in your message could be used in its place
    > with the expectation that something useful would happen (e.g.,
    > logging into the "archie" iSCSI target will not yield access
    > to the Archie service - why on earth would one want to tunnel
    > Archie over iSCSI?). It's a unique name for one of the targets behind
    > this  communication endpoint.
    >
    > > As this one machine
    > > may not be able to carry the load for all clients or connect to all
    > targets,
    > > would you then break connection to the iSCSI machine and then
    > make direct
    > > connections to the LUNs?
    >
    > Break the connection -Yes.  For communication load reasons -
    > not necessarily, as the connection can only be used to retrieve
    > target identifiers and can't access LUs.  To connect to a LUN - No,
    > the names returned name iSCSI targets, all of which share this
    > communication endpoint.   The session over which "Send Targets"
    > was sent is only useful for "Send Targets" because it's logged into
    > the canonical iSCSI target, which is only good for that purpose.
    > To access the actual targets, a new connection to foo.example.com
    > and a login to the target (one for each target) would be necessary.
    >
    > > Would a domain support multiple SCSI portals with
    > > other names like iscsi1 or iscsi2?  Is that also to be a standard
    > > convention?
    >
    > Sure, and I don't see the need to standardize that convention.  If someone
    > wants
    > to use blue-suede-shoes.example.com as a storage server that speaks iSCSI,
    > I don't see any problem.
    >
    > Hiding behind this is the question of how foo.example.com (or
    > blue-sued-shoes.
    > example.com)  was discovered in the first place - the answers to
    > that are to
    > be
    > found in the naming and discovery slides Mark used in Minneapolis - static
    > configuration, SLP, and iSNS can be used for this purpose.
    >
    > Please read the naming and discovery draft carefully before
    > continuing this
    > thread.  Much of the above is contained in it.
    >
    > --David
    >
    > ---------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 42 South St., Hopkinton, MA  01748
    > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    > black_david@emc.com       Mobile: +1 (978) 394-7754
    > ---------------------------------------------------
    >
    >
    
    


Home

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