Preliminary draft of minutes on SRP teleconference, September 24, 2001
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:
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
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)
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
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
DETAILS OF MEETING:
A) Document distribution.
The *.fdf file for the comments from Rob Elliott
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
C) Review of comments from Rob Elliott and others:
Most of these are editorial comments.
The technical editor was encouraged to change to
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
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
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.
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.
Capitalization needs to match up with IB where
IB QP will be changed to globally agree with the
definition. That requires IB to be added a number of
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
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.)
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
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
There is a feeling that 1.0.a is the correct reference,
but it should be discussed again on Friday.
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
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
"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
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