Preliminary draft of minutes on SRP teleconference, September 24, 2001

Robert Snively rsnively at Brocade.COM
Mon Sep 24 13:19:28 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*
TIME AND CONTACT INFORMATION FOR NEXT SRP TELECONFERENCE:

	Friday, Sept. 28:
	11:00am-2:00pm CST
	call in number: 281-518-9999
	pass code number: 9655712#
	Hosted by Rob Elliott at 281-518-5037.

AGENDA FOR NEXT MEETING:

	The following items are issues that are held over from
	this meeting and will be addressed at the next.  While
	Ed Gardner will begin applying many of the editorial
	fixes and well-understood changes, he will not post
	revision 9a.  Instead, the plan is to create a revision
	10 based on this work and the work to be completed
	on Friday.

	1)  Discussion of addressing structure and GUID
		Extension, Simpson/Haydt (see item B)

	2)  Discussion of choice of IB reference, 1.0 or
		1.0.a  (see item C, page 76)

	3)  Consideration of third-party behavior (Tyndall/Haydt)
		(see item D)

	4)  Consideration of removal of concept of processor unit
		(Brocade/Elliott)  (see item E)

	5)  Consideration of explicitly including redirection
		(Brocade/Rob Elliott/Cris Simpson)  (see item F)

	6)  Consideration of memory handle definition in IB.
		(Brocade/Rob Elliott)  (see item G)

	7)  Review any document changes that Ed Gardner identifies
		as requiring review (see Item C)

ACTION ITEMS:

   1)	Discussion of addressing structure and GUID Extension
		Cris Simpson and Rob Haydt will publish their
		proposals and counter proposals to resolve this
		question before the Friday meeting.
		See item 2 below.

   2) Ed Gardner will post these e-mail minutes to the 
		T10 web-site.  Ed may also post his notes on the
		document in .fdf format.

   3) Study of third party behavior and identification of
		any problems.  John Tyndall and Rob Haydt. 

   4) Review question on processor unit (item E)  Rob Elliott.

   5) Review question on redirection (item F) Rob Elliott and 
		Cris Simpson.

   6) Review proposal on memory handle definition for IB
		(item G)  Rob Elliott

   7) Ed Gardner will review and install the changes in item
	C and post any questions or resolutions resulting from
	those changes.

DETAILS OF MEETING:

A)  Document distribution.

	The *.fdf file for the comments from Rob Elliott 
	were distributed.

B)  Addressing structure questions

	Rob Haydt and Cris Simpson discussed the addressing structure.

	A GUID extension was proposed that could be assigned
	on a vendor basis.

	They concluded after further study that the 64-bit GUID
	extension was all that would be needed.

	At one time, they had thought of using multiple GUIDs
	to create this function.  

	There was a concern about determining whether or not
	there were separations between virtual and real targets.
	The additional 64-bits are not required for management.

	The present IB requires separate GUIDs for each IOC
	profile.  This requires extensions in the IBTA.  

	This caused considerable discussion, but no resolution.

	They concluded that something should go to the IBTA, but
	it should be sorted out first within T10.  Cris feels that
	the IOC profile needs work, and this is the good time to do
	the fixes.  Rob wants to keep this structure simple.

	Both will do formal proposals and we will solve this on
	Friday.

C)  Review of comments from Rob Elliott and others:

	Most of these are editorial comments.

	The technical editor was encouraged to change to 
	frame 6.

	Page 5 and 6 need to include the ANSI pages.  See 
	examples from SPI-4 or SPC-3.  Continue to use the
	same patent statement.  George and Ed will communicate
	about the proper format.

	Document will be optimized to reduce its file size.

	George Penokie's address will be corrected.

	Page 6, TOC format will be corrected.

	Page numbering should be readjusted in the PDF file and
	the page numbering should be corrected to be roman before
	the scope and numbered after clause 1.

	Line numbers will be preserved through the ballot cycle.

	Clause 2.2 shall have SPC-2 reference.

	Remove blank page before clause 4.  The ANSI editor
	appears to favor right hand page clause beginnings
	only for the first chapter.

	Section 3.1 uses the word "object" and the word "entity"
	apparently with the same connotation.  In most cases,
	the word "object" is consistent with SAM-2.  It was
	recommended that the word "object" be used in all 
	cases.  Each will be analyzed separately to see if the
	word entity is ever appropriate.  In some cases, 
	the definition already implies "object" and need not be
	specified again.  For reference, SAM-2 sometimes uses
	the word entity for logical units.

	SRP discovery clause 5.1.1.  The goal is to add the
	GUID with extension to the IOC profile.  This is the
	project being worked by Cris Simpson and Rob Haydt.

	The blank comment on page 29 is ignored.

	The document must be corrected to correct the pdf
	bookmarks, 6.2 - 6.13

	Page 38, correct reference to table as requested.

	Page 42, An editor's note needs to be removed.

	Page 48, correct fonts in table title.

	Page 52, correct fonts in table title.

	6.10, 6.11:  Ed proposes changing the name to:
	
		Credit Adjustment request/response.

		He proposes shortening them to 16 bytes.
		The proposal was accepted.

	Page 56, delete blank page.

	Page 58, Instead of explicitly accepting the proposal,
		Ed will cross-reference SPC-2 and use that wording.
		The wording will be propagated through the entire
		text as required.

	Page 58,  The references to the mode pages had been
		updated.  This change was accepted.

	Page 58,  "ration" should be "ratio".

	Page 66, delete blank page.

	Page 67,  Annex B should be moved to the end for future
		removal.

	Page 67,  Table B.1,

		Rob suggests reformatting this table.  Ed amends the
		recommendation to reserve 20 and above, since these
		are not part of this document.  These alias entries
		are associated with Jim Hafner's Access Control
		proposals.

	Page  69, Editor's Note 4

		C.2.1.3 defines IB Consumer.  3.1.7 defines it also,
		but without the use of verbs.  Then the IB Consumer
		could be a consumer that uses IB and the concept of
		verbs could be dropped out.

		C.2.1.20  IB Verbs is deleted as a concept.

	Clause C.2

		It is not clear "IB" is needed.  If it is, then the
		terms should be alphabetized with IB.  GID and GUID
		need IB in front of them.  This will require a global	
		change in clause C.

	Clause C.2

		Capitalization needs to match up with IB where
		appropriate.

	Clause C.2.1.15

		IB QP will be changed to globally agree with the
		definition.  That requires IB to be added a number of
		places.

	Clause C.2.1.14

		IB processor unit is used and is not capitalized.

		Note that the processor unit is not in the IB standard,
		but is in the IB architectural examples.

		(Note that removal of the concept of processor unit
		is being considered.)

	Clause C figure 7, page 71

		Universally correct figure numbering and references.

	Clause C figure 7, page 71

		Capitalize to match the document.

	Clause C figure 8, page 72

		IB should be included where appropriate as defined
		by the glossary.

	Clause C figure 8, page 72

		IO should be I/O universally.

	Clause C figure 8, page 72

		Capitalization in titles inside a figure.  The
		word "unit" should not be capitalized in text, but
		sometimes would be as a caption.  For our conventions,
		we will dictate that the capitalization used in the
		glossary, if any, will be used.

	Clause C figure 9, page 73

		The figure needs to be cleaned up a bit, but is
		otherwise okay.  The shaded area needs to be cleaned 
		up.  Ed Gardner will try to fix it.  Greg will use
		it as an instructional tool.  George will review it
		for correctness.

	Clause C figure 10, page 74 

		The figure needs to be cleaned up.  The same 
		actions will be applied to this.

		(Note that removal of this figure is being considered.)

	Page 72

		IPv6 is the format, not the actual address space of
		the GID.  This will be corrected.

	Clause C, table "A.33"

		The text needs to be properly capitalized,
		emboldened, and numbered.

	Page 76, line 46.

		Reference to IB spec should be upgraded to
		1.0.a.  

		Rob Haydt indicates that 1.0 is incompatible
		with 1.0, especially with respect to the 
		connection protocol.  The IBTA is still not
		providing guidance for this issue.  At present
		there is no way to distinguish the incompatible
		formats.  This is a significant problem.

		As long as we do not discuss the formats of the
		MADs, the reference revision should not matter
		to SRP.

		There is a feeling that 1.0.a is the correct reference,
		but it should be discussed again on Friday.

	Page 80

		Correct blank page


D)  Consideration of third-party behavior:

	Rob Haydt suggests that the management overlay should
	be left out of the SRP document as much as possible.
	He indicates that targets in a processor should work
	just like any standard targets.  There remains an issue
	with third-party operation.  In a third-party, is there
	a mechanism to transmit the necessary information
	without using the standard mechanisms.

	IB Third party may still be a problem.  There must be 
	a connection established, including a login and
	identification of a service id.  

	This requires some formal study within the organization.
	John Tyndall volunteered to look at this, because Crossroads
	has third-party experience.  Rob Haydt volunteered to work
	with him.

	Rob is concerned that these may provide impacts to the
	management of an IB fabric.

E)  Comment on definition of processor unit:

	The comment from Brocade was generally accepted in
	principle, but needs to be worked on by Rob Elliott.
	The definition of processor unit should be deleted.

	Here is the text of the Brocade comment:

	"What is the point of this "processor 
	units" vs. "IO units" exercise? "Processor unit" is NOT a 
	concept defined in InfiniBand. IOUs and IOCs are indeed 
	defined by IB in the Device Management context, but they are 
	to IB what logical units are to SCSI---abstractions for 
	purposes of representation that have no a priori relationship 
	to any specific underlying implementation. If a device is 
	going to operate in the role of a target, it must present the 
	appearance of being an IOU with IOCs regardless of the 
	device's intrinsic function or implementation---in other 
	words, it must look and act like an "IO unit" (and the text 
	so states, though not so succinctly). Similarly, if a device 
	intends to operate as an initiator, the IOU/IOC 
	representation is irrelevant, and there's no reason to care 
	whether the initiator is an IO unit or a processor unit.

	If the point of the exercise (and I'm speculating here) is to 
	suggest that a target that also acts as an initiator should 
	keep the same port identifier in either role, well, it 
	probably ought to say that.

	The bottom line here is that figure A.9 should be kept
	as-is (except that the "processor unit" labels need be 
	elided), and Figure A.10 should be deleted. The text 
	needs to be similarly adjusted."

F)  Comment on redirection:

	Brocade provided the following comment concerning
	redirection.

	"p. 75: Section C.6.3: would it be worthwhile adding something 
	to the following effect? "A target MAY generate CM:Reject 
	messages for the purposes of redirecting a connection by 
	setting the CM:Reject Reason field to 24 or 25, and that an 
	initiator SHOULD recognize such rejections as redirections, 
	and retry the connection requests as redirected." 
	This functionality is already in the IB 
	Connection Manager spec, but feels like the kind of thing 
	that a lot of implementers might mindlessly blow off without 
	appropriate encouragement. Maybe it's a non-issue, but this 
	redirection is shaping up as an important function."

	This was considered, but needs review by
	Rob Elliott and Cris Simpson for details.  Brocade
	feels that this is an important functionality.

G)  Comment on memory handle definition for IB

	No one has seen this in the document, and it is agreed
	that this needs to be included.  This will be reviewed
	by Rob Elliott.  The text of the comment from Brocade is:

	"As defined in Table 1, a memory descriptor contains 
	a virtual address, a memory handle, and a data length. 
	InfiniBand does not make use of a memory handle as 
	such---it's implicitly defined by the QP to which an RDMA 
	operation applies.

	InfiniBand does, however, define the notion of an "Remote 
	Key", or R_Key, that's associated with each memory area made 
	available for RDMA access. The R_Key must be present in the 
	RDMA Extended Transport Header (RETH) found in each 
	RDMA---related IB packet, and perforce must be communicated 
	from the initiator to the target as part of each memory 
	descriptor. The fairly obvious choice is to stick the R_Key 
	value into each memory descriptor's memory handle field; but 
	it seems like this ought to be explicitly stated."

ATTENDEES (spelling not guaranteed):

John Tyndall		Crossroads
George Penokie		Tivoli/IBM
Greg Pellegrino		Compaq
Bob Griswold		Crossroads
Cris Simpson		Intel
Ed Gardner			Ophidian
Nathan Ober			Microsoft
Rob Haydt			Microsoft
Bob Snively			Brocade
*
* 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