Subject: [Ips] RE: Ips Digest, Vol 15, Issue 9

From: "Prashanth Nednoor" <[email-masked]>
Date: Tue, 26 Jul 2005 14:50:14 -0700

Jhyling,
 
wahts is the argument to run 4022 in diag mode, 
 
i have the logic in the code....
 
thanks
prashanth

	-----Original Message----- 
	From: [email-masked] on behalf of [email-masked] 
	Sent: Tue 7/26/2005 9:09 AM 
	To: [email-masked] 
	Cc: 
	Subject: Ips Digest, Vol 15, Issue 9

	Send Ips mailing list submissions to
	        [email-masked]
	
	To subscribe or unsubscribe via the World Wide Web, visit
	        https://www1.ietf.org/mailman/listinfo/ips
	or, via email, send a message with subject or body 'help' to
	        [email-masked]
	
	You can reach the person managing the list at
	        [email-masked]
	
	When replying, please edit your Subject line so it is more specific
	than "Re: Contents of Ips digest..."

	Today's Topics:
	
	   1. iSNS MIB Changes (Scott Kipp)
	   2. Re: ISID and Discovery Re:
	      draft-ietf-ips-iscsi-impl-guide-00.txt (Robert D. Russell)

	----------------------------------------------------------------------
	
	Message: 1
	Date: Mon, 25 Jul 2005 10:09:23 -0600
	From: "Scott Kipp" <[email-masked]>
	Subject: [Ips] iSNS MIB Changes
	To: <[email-masked]>
	Message-ID:
	        <[email-masked]>
	Content-Type: text/plain;       charset=iso-8859-1

	iSNS MIB Reviewers,
	
	I would like to announce the miraculous recovery of the iSNS MIB.  After revision 6 of the iSNS MIB expired, G D Ramkumar and I were tasked to complete revision 7 of the iSNS MIB with the help of Kevin Gibbons.  Kevin has been assigned other duties within McDATA and was unable to champion this effort with his busy schedule.  You have probably seen that the new revision has been posted and I would like to discuss the changes that were made on the reflector and in the meeting next week.
	
	Here are the changes that were made to the draft: 

	        1.      Added clarification to DESCRIPTION of isnsClntCfgSrvrTable specifying that the role of the server is not covered by this table.
	                        "The active/backup role of the configured server
	         is not within the scope of this MIB and hence not included in this table."

	        2.      Added above clarification to DESCRIPTION of isnsClntDscvrdSrvrTable as well.
	                        " The active/backup role of the discovered
	         server is not within the scope of this MIB and hence not included in this table."

	        3.      Removed these fields from the isnsClntInstTable, from isnsClntInstEntry
	               isnsClntInstAddressType     InetAddressType,
	               isnsClntInstAddress             InetAddress,
	               isnsClntInstTcpPort             Integer32
	               isnsClntInstUdpPort             Integer32
	
	              These were removed because these fields are not required to describe the client and they unnecessarily restrict the client to a single IP address and port.
	
	               Removed these fields also from the corresponding conformance table, isnsClientAttributesGroup
	
	        4.      Removed one of duplicate "the" in the description of "isnsClntCfgSrvrEntry"
	
	        5.      Remove isnsClntDscvrdSrvrIndex from the isnsClntRegEntityEntry table.
	                Add     isnsClntRegEntityAddrType       InetAddressType,
	                            isnsClntRegEntityAddr               InetAddress,
	                            isnsClntRegEntityTcpPort           Integer32,
	                            isnsClntRegEntityUdpPort           Integer32
	
	                This change is to decouple the isnsClntRegEntity table from the isnsClntDscvrdSrvr table so that it can more accurately reflect the entities that are being reported to the servers.
	
	                These fields are also added to the conformance table isnsClientAttributesGroup
	
	Au Revoir,
	Scott

	SPECIAL NOTICE
	
	All information transmitted hereby is intended only for the use of the
	addressee(s) named above and may contain confidential and privileged
	information. Any unauthorized review, use, disclosure or distribution
	of confidential and privileged information is prohibited. If the reader
	of this message is not the intended recipient(s) or the employee or agent
	responsible for delivering the message to the intended recipient, you are
	hereby notified that you must not read this transmission and that disclosure,
	copying, printing, distribution or use of any of the information contained
	in or attached to this transmission is STRICTLY PROHIBITED.
	
	Anyone who receives confidential and privileged information in error should
	notify us immediately by telephone and mail the original message to us at
	the above address and destroy all copies.  To the extent any portion of this
	communication contains public information, no such restrictions apply to that
	information. (gate01)

	------------------------------
	
	Message: 2
	Date: Mon, 25 Jul 2005 12:27:20 -0400 (EDT)
	From: "Robert D. Russell" <[email-masked]>
	Subject: [Ips] Re: ISID and Discovery Re:
	        draft-ietf-ips-iscsi-impl-guide-00.txt
	To: "Mallikarjun C." <[email-masked]>
	Cc: IPS <[email-masked]>
	Message-ID: <[email-masked]>
	Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
	
	Mallikarjun:
	
	> Yes, I will certainly consider.  Please send me a URL to a decent summary
	> email in that thread.  Or please do me a favor by writing up one if a summary
	> doesn't exist.
	>
	
	Attached below is my draft of a proposed clarification
	based on two long threads that appeared on the reflector in
	August, 2004, both having to do with the uniqueness of iscsi
	sessions and I_T nexus identifiers.
	
	The first thread appeared under the heading:
	"ISCSI Name and Multi-Port Targets", starting with
	http://www.spinics.net/lists/iscsi/msg10052.html
	
	The second thread appeared under two headings:
	"final resolution of ISID rule as it applies to discovery sessions",
	starting with http://www.spinics.net/lists/iscsi/msg10129.html
	and (note the missing space)
	"final resolution of ISID rule as it applies to discoverysessions",
	starting with http://www.spinics.net/lists/iscsi/msg10142.html
	
	In writing this summary I realized that the "final resolution of the
	ISID rule for discovery sessions" thread never mentioned what to do
	about the Portal Group Tag in the I_T nexus identifier when the
	Target Name was omitted during the first login request of a
	discovery session.  It seems to me that without the Target Name
	no Portal Group Tag can be uniquely determined, even based on the
	IP address and port number used by the initiator to connect to the
	target (since that IP address and port number can belong to different
	portal groups under different Target Names used by the same target
	network entity).  I therefore wrote in the summary that the Portal
	Group Tag component of the I_T nexus identifier was also NULL or ""
	in this case.
	
	Comments?
	
	Thanks,
	
	Bob Russell
	InterOperability Lab
	University of New Hampshire
	[email-masked]
	603-862-3774
	
	---------------------------------------------------------------------------
	
	Uniqueness of iSCSI sessions
	----------------------------
	
	According to Section 3.4.2 c) of RFC 3720, the SCSI "I_T nexus" defined
	in SAM2 is equivalent to the iSCSI session defined in RFC 3720.
	This section also defines the "I_T nexus identifier" to be the tuple:
	
	    (iSCSI Initiator Name + 'i' + ISID,
	     iSCSI Target Name + 't' + Portal Group Tag)
	
	where both the iSCSI Initiator Name and iSCSI Target Name are
	intended to be world-wide unique names.
	
	Therefore, two such tuples with a difference in any one of the four
	components will identify two different I_T nexi and therefore two
	different iSCSI sessions.  This has several implications:

	1) An initiator may use the same iSCSI Initiator Name and ISID when
	    establishing different (i.e., unique) sessions with different targets
	    and/or different portal groups.  This behavior is discussed in section
	    9.1.1 and is, in fact, encouraged as conservative reuse of ISIDs.

	2) According to section 9.1.2, there is intended to be just one iSCSI
	    Initiator Name per operating system image on a machine.  Therefore,
	    when multiple initiators are running on the same operating system
	    image on the same machine, they should all share the same
	    iSCSI Initiator Name and manage the ISID name space between them
	    to avoid conflicts (e.g., by appropriate partitioning).

	3) The I_T nexus identifier applies to all session types (normal and
	    discovery).  When an initiator supplies a Target Name on the first
	    login request of a discovery session, there is a Portal Group Tag
	    associated with that Target Name and formation of the I_T nexus
	    identifier is straight-forward.  However, according to section
	    3.2.6.1, the initiator MAY omit supplying the iSCSI Target Name on
	    the first login request of a discovery session, in which case the
	    I_T nexus identifier is constructed by supplying an empty value
	    (e.g., NULL or "") for both the iSCSI Target Name and the Portal
	    Group Tag components.  The consequences of this are:
	
	    a) The I_T nexus identifier of a discovery session established WITH a
	       Target Name MAY match the I_T nexus identifier of a normal session,
	       in which case such a discovery session will force reinstatement of
	       an existing normal session (and vice versa) as defined in section
	       5.3.1.
	
	    b) The I_T nexus identifier of a discovery session established WITHOUT
	       a Target Name NEVER matches the I_T nexus identifier of a normal
	       session, so that such a discovery session NEVER forces reinstatement
	       of an existing normal session (and vice versa) as defined in section
	       5.3.1.
	
	    c) At any time, a single target should have at most one discovery
	       session with the I_T nexus identifier:
	       (iSCSI Initiator Name + 'i' + ISID + "" + 't' + "")

	
	------------------------------
	
	_______________________________________________
	Ips mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/ips

	End of Ips Digest, Vol 15, Issue 9
	**********************************

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips