[SRP] March 1 Meeting Notes

Simpson, Cris cris.simpson at intel.com
Tue Mar 5 12:22:27 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Simpson, Cris" <cris.simpson at intel.com>
*

Attendees:

Chuck Gibson		Adaptec
Bob Snively		Brocade
Brian Forbes		Brocade
Dave Peterson   	Cisco
Rob Elliott 		Compaq
Bob Griswold 		Crossroads
Bob Nixon       	Emulex
Ralph Weber    		ENDL
Santash Rao     	HP
Randy Haagens        	HP
Mallikarjun Chadalapaka	HP
Giles Frazier   	IBM 
George Penokie		IBM
Cris Simpson 		Intel
Nathan Obr 		MSFT  
Rob Haydt			MSFT
Ed Gardner			Ophidian
Gerald Maurer    	QLogic
Roger Cummings 		Veritas



Old Business__________________________________


1. IBM050

BobS: Reservations are a poor tech for networked devices, why not obsolete?

CrisS: Anyone want to speak up for classic reservations?

DaveP: Time better spent on PRs...

RogerC: Let's obsolete for NEW stds, let legacy keep.

RobH: We don't have any problems with obsoleting classic reservations.

RobE: What about Mode Pages, Log Pages?

GOP: You should save them anyway.  
     Keep MPs and LPs separate from intconn.
     (FC clears when last init logs out.)

<AR> DaveP - Proposal for obsoleting classic reservations

Mode pages
  FCP clears MPs only when all sessions drop
  GOP - don't even do it then

RobH:
 When we re-login, we assume that no state is valid, reset everything -
easier than looking.

GOP: Reasonable implementation - but std shouldn't require


RobE: Let's expand to Log Pages.  LPs cleared on (some) resets.
      Does FC Logout clear LPs?  

RogerC: No 

RobE: There are other events that FC says cause clearing
      Will send out list (Sent March 1)

RandyH: The real issue is the lifetime of an I_T(_L) nexus.

BobS: I've got SCSI-2 chapter and verse (r10L 3.1.28) defining duration of
nexuses
      ROW: Only meaningful for pSCSI
      BobS: See also SAM-2 (r22 4.10, 3.1.68) crossref I_T nexus object 
            only instantiated (derived) in the MIB


RESOLVED: Classic reservations to be obsoleted. 
          DaveP will get on CAP agenda

MPs and LPs to wait for CAP.

BobS: New concept: "SAN domain" 
  Randy: Brings time into scope - if you can't talk to a device, 
         why keep the state?   Sometimes, tossing state is a good thing to
do.

EdG: Maybe we should prohibit mode pages per intiator

RandyH: Can support MPs/init through virtual targets

RobE: Port Control MP is per-init

RandyH: In networked world, targets should discard state at every
opportunity.



New Business___________________________________

1. CPQ015 : MSB/LSB for Tag

   Ed: What harm is there in having MSB/LSB?
   GOP: For consistency, we need it, like other single-field values.
   Ed: Need it for analyzers. (Argument carries - keep it)


2. Edit005 : 
   SPC-3 says "These [alias] associations shall be cleared under any event
that resets the logical unit and events designated by the SCSI protocol." 
   It appears that we need to have a list or a statement that there are no
such events. Where would it go, what would it say?

   (RobE will include in list of issues for resolution at CAP)

3. intel041:  may/shall send I_LOGOUT

   Change to "SHOULD send" 

4. intel042:  should/shall send T_LOGOUT
   
   Stay w/ SHOULD.

5. intel044:  LOGIN_REJ reason code  

    Add new code:"RDMA Channel limit reached for this initiator see (5.1.3)"

6. intel084: replace 'count' with 'PMDL Length'

   Ed liked it that way first, but wants keep it stable.
   See if cleaner.


7. intel094: optional IUs?

   All are Mandatory.

8. intel096: T_LOGOUT reason code for bad length?

    Add new code


Next meeting_____________________________________________

March 08 0900-1100 PST
1.888.316.5901 or +1.617.801.9781
Passcode: 7710.3528



--
Cris Simpson                                          503.712.4333         
Intel EPG/ACD Architecture                           Hillsboro, OR   
PGP Fingerprint:0DA0 418E A27B 0B76 5F02  3DD4 0546 6D13 F88A 1E60
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list