RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]

["Douglas Otis" <dotis@sanlight.net>]

Joshua,

> Doug,
>
> I'm not sure we understand each other anymore.  I will just carefully
> restate my points, and leave it at that.
>
> 1)  URL's (domain name & path) are needed in the iSCSI transport to
> support proxy services.  Because of the prevalence of NAT, proxies
> are necessary.

Most likely, a DNS response will be inadequate in providing needed
information for making a connection if it is more than a simple IP.  At this
point, there are no SCSI proxy servers that rely on names so there is no
prevalent use making a SCSI address translation which depends on a SCSI name
server.  This is an invention you are suggesting.  You are suggesting the
use of names is required.  That is not true!  You are recommending mapping
SCSI drives into a directory scheme as denoted by your domain/path.  You
insist this is the only means of addressing SCSI drives.

See:
http://www.ietf.org/rfc/rfc2251.txt

Lightweight Directory Access Protocol (LDAP) is a distributed, hierarchical
directory service access protocol used to access repositories of users and
other network related entities. Information such as users found in NIS (flat
file) should derive from LDAP as authoritive to take advantage of LDAP
scalability.  The "DUA" (directory user agent) refers to the LDAP client
querying these entities, such as an LDAP to NIS gateway or SCSI services.
It is irrelevant whether the DUA and the client reside within the same
address space.  The DUA giving this information to the client is termed
"republishing".

You *WILL* map drives to directories because this is how LDAP works!  You
still have the joy of inventing names to act as place holders.  The
important aspect of making use of this server, you discover all the mappings
before making connection to this proxy or portal.  (Access to the portal
MUST be routable from the gateway or there would not be any means to connect
nor would access to the portal depend on embedded names.)  By doing so,
there is no need for the portal to do any lookups real-time or need to embed
names and in doing so weakening security.  If you want a SCSI transport to
scale, do not expect name translations done in real-time.

> 2)  Authentication is a separate issue and has nothing to do with
> identifying the final destination device/LUN/WWN of the iSCSI traffic.
> A separate key distribution server may improve scalability of the
> authentication mechanism, but this has nothing to do with addressing
> and routing of iSCSI traffic.

Each name must be examined and resolved before an authentication check can
be made.  By not embedding names, the address would already be resolved by
LDAP in advance and far easier to check.

> 3)  A LANE-type architecture for addressing and routing of iSCSI
> traffic is a bad idea due to scalability and management issues.
> The iSCSI transport must have imbedded routing information in the
> form of a URL, to allow proxies and destination nodes to route
> iSCSI traffic to its final device/LUN/WWN destination.

It will take less effort to re-route a pre-resolved address than to first
resolve the address and then remap it.  If the portal only needs the
device/lun/wwn to do routing then that should be all that is given.  LDAP
does not constrain the information embedded, only that it should not be
resolved by the portal via your invented SCSI name server.  We are not here
to re-invent the wheel and it makes no sense to do this live should you wish
this equipment to scale.

Doug

> Best regards,
> Josh Tseng
>
> -----Original Message-----
> From: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Tuesday, October 03, 2000 11:13 AM
> To: Joshua Tseng; ips@ece.cmu.edu
> Subject: RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
> Joshua,
> <snip>
>
> > What you describe might be possible (although I still think it's a bad
> > idea) if the entire Internet, including all public and private networks,
> > were in a single consolidated address space.  But the fact is we are
> > running out of address space, and there is something called NAT defined
> > in RFC1918.  Who knows, with IPv6, this may change, or it might
> not.  But
> > it is a reality today.  To operate in an environment with NAT, you need
> > proxies.  There's no way around it.  A client in a public network using
> > registered IP address space should NEVER see a 10.0/8 address.
> It should
> > NEVER talk to a 10.0/8 address, and it shouldn't even have a 10.0/8
> > address entry in its routing table.  It must first talk to a dual-homed
> > proxy with at least one leg using registered IP address space, in order
> > to communicate with a host with a 10.0/8 address.  In this environment
> > and with these restrictions, I don't understand how you can remove the
> > involvement of the proxy in the process of what you call
> "authentication".
> >
> > BTW, it's not just http--e-mail and many other applications today make
> > extensive use of proxy relays as well.
> >
> > Josh
>
> Yes, and most enterprise environments include a NAT.  Even homes with DSL
> include NAT.  A few may even use a proxy.  That does not mean private
> addresses of the target can not be shared at the time of
> authentication.  I
> would have expected such an exchange.  As most of these things work, such
> permission is in the form of a lease.  I would also expect as the map is
> declared, mapping screens are established based on the permission
> discovered
> at the time of authentication.  Before and not during use.  Using a binary
> address does not mean PUBLIC addresses.  It may not even be IP.
> It could be
> SCSI address or perhaps an encoded address.  You do not want SCSI to look
> like an HTTP server.  Especially if you wish this application to
> scale, you
> do not want to be doing in-band name lookup and authentication.
>
> Pleases, this is not a web server, it is a portal to SCSI
> devices.  A client
> does not need to use a name to get a proxy to listen, try just
> typing the IP
> of a web site.  The proxy will forgo the lookup.  Name lookup is simply a
> convenience for humans.  You would not want to depend on a round-robin
> selection of IPs from DNS should there be more than one such IP.
> How would
> you select the alternative IP, the next in the list?  All these parameters
> can be concisely defined in the authentication exchange.  I can
> not see why
> someone would wish to place a name on their SCSI portal but they
> could.  The
> only name that needs to exist is the authentication server.  I would not
> expect an address beyond the SCSI portal to be PUBLIC IPs.  I would not
> expect them to be IP.  LDAP is good at doing symbolic lookup.
> Let it do the
> work at the time of authentication.  Don't invent a SCSI browser.
>
> Doug
>