RE: iSCSI: corrections to Appendix D:SendTargets

[pat_thaler@agilent.com]

Julian,

 

Part of the problem is that the term "system" covers a very broad range of things. The current wording requires every IP address in a system to be able to be attached to the iSCSI service. There are reasonable implementations that would be prohibited by such a requirement.  E.g. one could have a box containing storage plus separate NAS and iSCSI controllers each with their own IP addresses and LAN interfaces. Such a box could be considered a system containing targets and the IP address that goes to the NAS controller doesn't have an iSCSI service available to it. I don't see why we should prohibit this implementation.

 

The term "iSCSI IP address-port pairs," used in the text proposed in your other email seems reasonable.

 

Pat

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, June 06, 2002 9:08 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; marjorie_krueger@hp.com
Subject: RE: iSCSI: corrections to Appendix D:SendTargets

Pat, 

I have trouble understanding your 
statements  WRT to IP addresses. You should be able to use addresses to 
whatever you want the port is what distinguishes the service (iSCSI or NAS) - if 
you wish (that is the usual practice) and will allow you to use a common 
physical interface for various services. 

However TCP addresses is a somewhat unusual term - addresses are IP - 
iSCSI is serviced at specified (or well known) ports. 

Julo

pat_thaler@agilent.com 06/06/2002 04:02 AM Please respond to pat_thaler

To:        marjorie_krueger@hp.com, Julian Satran/Haifa/IBM@IBMIL         cc:        ips@ece.cmu.edu         Subject:        RE: iSCSI: corrections to Appendix D:SendTargets

Marjorie, 

IP addresses shouldn't be changed to TCP addresses 
because that could
be interpreted as meaning it needs to support SendTargets 
on ports connected to 
non-iSCSI ports.

Thinking about that, I also 
don't think it should be required to support 
disovery sessions on each IP 
address. It seems reasonable for a system to have
some IP addresses that 
aren't connected to an iSCSI protocol at all. For example
one might build a 
box with storage that does both iSCSI and NAT and one might choose
to use 
different IP addresses for those two services. One might do that because the 
services are on different LAN interfaces or for numerous other reasons. 

I think the text should be something more like: "on each IP address that 
supports
iSCSI".

Regards,
Pat

-----Original 
Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)

to the 
following:

    A system that contains targets MUST support 
discovery sessions on each 
    of its TCP addresses, and MUST 
support the SendTargets command on the 
    discovery session. 
 A target MUST return all path information (TCP 
    addresses 
and portal group tags) for the target in question for
    which the 
requesting initiator is authorized.

    A target MUST support 
the SendTargets command on operational sessions;
    these will 
only return path information about the target to which 
    the 
session is connected, and need not return information about other 
  
  target names that may be defined in the responding device.

This is 
just an explicit statement of what's implicit in the current
appendix. 
 I corrected "IP address" to "TCP address" cause it's the TCP
listening 
port that must provide the discovery session.

Also, on page 234, the 
paragraph:

    After obtaining a list of targets from the 
discovery target session, 
    an iSCSI initiator may initiate new 
sessions to log in to the discov-
    ered targets for full 
operation.  The initiator MAY keep the session 
    to a 
default target open, and MAY send subsequently SendTargets com-
    
mands to discover new targets.

Should be changed to 

    
After obtaining a list of targets from the discovery target session, 
  
  an iSCSI initiator may initiate new sessions to log in to the 
discov-
    ered targets for full operation.  The initiator 
MAY keep the discovery
    session open, and MAY send subsequently 
SendTargets commands to
discover
    new targets.

On page 
235, the paragraphs:

    In the above example, a DNS host name 
could have been returned instead 
    of an IP address, and that an 
IPv6 addresses (5 to 16 dotted-decimal 
    numbers) could have 
also been returned.

    The next text response shows a target 
that supports spanning sessions 
    across multiple addresses, 
which indicates the use of the portal group 
    
tags:

Should be

    In the above example, a DNS host 
name or an IPv6 address (5 to 16
    dotted-decimal numbers) could 
have been returned instead 
    of an IPv4 address.

  
  The next text response shows a target that supports spanning sessions 
    across multiple addresses, and illustrates further the use of 
the 
portal
    group 
tags:

Thanks,
Marjorie