Subject: RE: iSCSI: corrections to Appendix D:SendTargets

From: "Julian Satran" <[email-masked]>
Date: Thu, 6 Jun 2002 19:08:18 +0300

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

[email-masked]
06/06/2002 04:02 AM
Please respond to pat_thaler

        To:     [email-masked], Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        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

---

From: [email-masked]
Date: Thu, 6 Jun 2002 10:48:33 -0600

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:[email-masked]]
Sent: Thursday, June 06, 2002 9:08 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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 

	[email-masked] 

06/06/2002 04:02 AM 

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.

Regards,
Pat

-----Original Message-----

to the following:

    A system that contains targets MUST support discovery sessions on each 

    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.

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.

    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

Thanks,
Marjorie