FC-TAPE July 1998 Minutes
stewart at hpbs3928.boi.hp.com
Fri Jul 17 11:04:22 PDT 1998
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Stewart Wyatt <stewart at hpbs3928.boi.hp.com>
Joint FC-TAPE Ad Hoc Meeting, July 14, 1998 - Portland, Maine
Stewart Wyatt FC-TAPE secretary
The meeting began shortly after 1:30 PM and adjourned between 8:30 and
9:00 PM. Facilitator Dale LaFollette ordered in pizza for the
participants who stayed late. Good progress was made by extending the
meeting. The group wishes to thank Dale for the pizza.
1. Introductions: Facilitator Dale LaFollette, StorageTek, called the
meeting to order and had the participants introduce themselves as is
2. Approval of this Agenda: T11/98-348v0 The minutes were approved
after adding "Target reset" to item 10. T11 New Business.
3. Approval of 6/10 Minutes: T11/98-296v0: Secretary Stewart Wyatt,
HP, reviewed the last months minutes. The following corrections were
Item 5, sixth paragraph, George Penokie's name is misspelled.
Item 7, A extraneous line needs to be deleted.
Items 7a and 9 the reference to the editors meeting should be an ad
4. Old Action Items: The action items from last months minutes were
reviewed. Note: These first three action items were to be completed in
two weeks to enable reflector discussion previous to the July T10
Neil Wanamaker: Prepare flow diagrams for CRN proposal. Neil reported
that Ed Gardner, Ophidian Designs, had taken this action item.
Dave Baldwin: ABTS proposal. Dave Baldwin, Emulex, was not in
Dave Peterson: Updated draft focusing on clause 9. Completed on time.
Editor Dave Peterson, StorageTek, had revised clause 9 and circulated
it on the reflector over two weeks earlier. Last week he had revised
the entire profile which had been posted to the ftp site.
Dale Lafollette: Investigate lengthening the FC-Tape meeting during
T10 week in Portland, ME. Completed.
Depending on the progress made in Maine, an additional editor's
meeting will be scheduled before England. Pending the outcome of this
Tape Vendors: Reply to Bob Snively's proposal to require FLOGIN
mandating that all devices be public. Dale LaFollette, StorageTek, Jim
Jones, Exabyte and Stewart Wyatt, HP, had all replied negatively by
posting to the reflector.
5. CRN Completion
Ed Gardner took the floor. He had not created the flow diagrams as he
felt there were issues that needed to be resolved before he could
proceed. A discussion of CRN issues started mostly between Dal Allan,
ENDL, and Doug Hagerman, Compaq (was Digital) which quickly became
heated. Dal Allan argued that a value of "0" in the CRN should be
interpreted as "no CRN present" This would provide two functions. It
would enable older implementations such as PLDA disk drives to be
compliant since they would treat the field as reserved as required in
the FCP and set it to "0". Setting the CRN to "0" for task management
functions (TMF) would enable a TMFs to get through the "fire wall" in
the case of a target that had stopped executing commands because of a
missing CRN and would avoid a deadlock by enabling the host to clear
out the error condition. Doug felt that TMFs should be required to
have CRNs and that all missing commands should be recovered before
they were forwarded for processing. Doug felt that Fibre Channel had
made a fundamental error in failing to order exchanges and that the
CRN field offered a remedy to that situation. The problem is to make
sure that everything is delivered independent of the content. Doug
felt that if a command was missing, something was broke and needed
fixing. Dal argued that it probably just indicated a failure in the
port that should be recovered without interfering with other devices
on the loop.
Dal Alan had another issue with CRNs. The way they are defined they
operate at neither the target or LUN level. Dal drew an example on the
board of a subsystem that is a target for the host and an initiator
for the drives. Who is managing the CRNs, the subsystem or the drives?
Ed Gardiner, Bob Snively and Rob Bashim, IBM, felt that CRNs should be
LUN centric given that a CDB is a LUN widget. However some TMFs are
target and some are LUN functions. Bob Snively pointed out that most
TMFs are target operations.
Doug Hagerman wanted an example where a TMF is required that precludes
using the CRN. Rob Bashim brought up the issue of high availability
systems where two hosts are working with out of band communication
with failover without initialization using a checkpoint data base.
Dale LaFollette was getting tired of the discussion which by this time
had taken over an hour. He called for a binding straw poll asking how
many wanted CRNs in TMFs. Two were in favor and the rest of the room
Doug Hagerman brought up an example of a case where he felt CRNs were
needed on TMFs. Suppose an initiator sends TMF to clear a queue. One
of the commands is out of order and arrives after the TMF even though
it was sent before. The initiator thinks all of the commands were
cleared when one was not. Bob Snively replied that this scenario was a
violation of the FCP procedures. The correct approach would be to
perform an abort on each command with an RRQ.
Ed Gardiner threw out another suggestion. He wanted a flag to signal
that the CRN was valid. This was discussed at length.
Dale LaFollette called for another vote:
First option: CRNs roll from 255 to 0 with no flag bit - 2 in favor.
Second option: CRNs roll from 255 to 1 with no flag bit, "0" implies
no CRN - 10 in favor.
Third option: CRNs roll from 255 to 0 with a flag bit - 4 in favor.
Ed Gardiner expressed an interest in defining a new feature that would
enable a command to be aborted if it has not been started but left
alone if it has. Bob Snively countered that he, Doug Baldwin and Dave
Peterson would be working on fixing ABTS and that should be part of
that discussion which more properly belongs in the FCP-2 discussion
that would be occurring during the next day. Ed's other concerns
related to out of order issues. The group protested and stopped the
discussion which was said to apply to FCP-2 discussions and not to the
Dal returned to his target versus LUN centric discussion. At issue was
whether the capability should be conveyed in a mode page which is LUN
centric or PRLI which is target centric. The group was converging on
CRNs as LUN related but wanted to use PRLI for indicating capability.
Neal Wanamaker, Crossroads, felt that CRNs worked better with process
logins. As an example, it takes a command to send the mode page to set
up the CRNs. Bob Snively felt that the capability may need to be set
up with both. Dal Allan was concerned about mixing and matching LUN
and target functions in mode pages and PRLIs. Rob Bashim categorized
the issue as a bootstrapping problem. This idea resonated with the
group. Dal Allan agreed, but instructed the editor to clearly state
the issues to provide a document trail to avoid setting a precedence
that might be abused later.
In response to a question Bob Snively explained that both the CRN and
FCP-CONF will be officially defined in FCP-2. In the meantime the tape
profile will include the definitions as a normative annex. The annex
will eventually be replaced when FCP-2 is available.
Neil Wanamaker took the stand to discuss FCP_CONF. He put up an
overhead that contained the following text:
Bullet 1. Enabled by PRLI
Sub-bullet: Byte 3 bit 7 to enable FCP_CONFIRM
Bullet 2. Requested on each FCP_RSP requiring confirmation
Sub-bullet: Byte 2 Bit 4 indicates FCP_CONF required
Sub-bullet: Last Sequence bit not set in F_CTL
Bullet 3: FCP_CONFIRM has IC=3 information category
Sub-bullet: no payload
Neil thought this was what had been agreed on. After the previous
discussion and noting bullet 1, he said he was willing to move the
enable from PRLI to a mode page. Ed Gardner argued that it needed to
be left in. He gave as an example a target LUN being swapped where the
replacement should assume the function. He thought that this was
another "boot strapping" issue. The group agreed to leaving the enable
in the PRLI.
The second bullet was changed to "Requested on each FCP_RSP for which
target requires confirmation" to make it clear who does the
requesting. It was also noted that FCP_CONF is class independent - it
is not necessarily a "Class 3 thing".
Dale LaFollette put this definition of FCP_CONF to a vote -14 were in
favor and none were opposed.
7. Flogin Requirement:
Since the issue had been debated on the reflector, Dale LaFollette
tried to call for a vote without a discussion. However the issue of
what was to be voted upon triggered the discussion anyway. Dal Allan
wanted one profile that supports both public and private operation.
Bob Snively argued that constitutes two profiles. Bob says he wants
public devices within 4 months after private devices are available. He
wants the profile to send a strong message supporting public behavior.
He argued further that being noncompliant is not such a big deal for
those who initially offer private devices. It is usual for a company
to print a list of exceptions for a new product. Stewart Wyatt asked
how an application that did not want the tape to login could prevent
it. Rob Bashim argued in favor of public operation saying it isn't
that hard for a tape drive to implement it. Roger Cummings, DPT,
argued for requiring public behavior by pointing out that short term
decisions have always been bad for Fibre Channel.
The subject for voting was changed from Bob's original proposal of
requiring FLOGI to being an FLA public loop compliant device. The vote
was 11 in favor and 4 opposed. (Had the motion failed the group would
have voted on the number of profiles to be written. With the decision
to be public this became irrelevant.)
8. FC-TAPE Draft Review - Dave Peterson
Bob Snively had posted a large document to the reflector containing
comments on the profile. Apparently the document was large enough that
some participant's email could not receive it.
Bob Snively was given the floor to review his comments. He choose to
focus on a few that he thought were most important:
#30 A general statement that Bob has expressed before that he wanted
to limit the number of `
"allowed" items to a minimum. To ensure interoperability he wanted
items to be "required" or "prohibited".
#32 Some specific suggestions of changing items from allowed to
prohibited. In response to Matthew Wakeley, HP, about compliance
testing, Bob discussed the meaning of the terms allowed, invocable,
prohibited, etc. Matthew's concern was that he not be "dinged" in
compliance testing for not using a feature prohibited by the profile.
The consensus was to remove references to unfairness and transfer
state use making the profile silent on these issues.
LPE/LPB Origination "prohibited" went to a vote -12 to prohibit, 2
LPE/LPB Recognition - delete reference "bunch" in favor and 1 opposed.
MRKtx origination, no defined use, voted to prohibit 14 for, 1 opposed
- Editor Dave Peterson was the single dissenter. He was challenged to
provide an application for group consideration.
Command linking prohibited - 10 voted yes, no one was opposed.
Class independent single profile - previously agreed to.
Bob proposed prohibiting ACA usage given. Dale LaFollette felt it was
necessary in a queuing environment where a write fails and additional
writes were received before the initiator can provide error recovery.
Dale saw ACA as providing the capability of causing the tape to stop
processing additional commands in the queue after a failure. ACA
should be required in a queuing environment. A long discussion
followed. Bob Snively stated a warning that he wants one driver that
works for all FC-TAPE vendors where today every tape vendor requires a
different driver. The issue was put to a vote, NACA is required for
queued commands (NACA =1) and prohibited for non-queued commands -
approved 11 to 1.
#53 review of SCSI commands. Bob wanted to define which SCSI commands
should be supported and which could be prohibited. The first command
he considered was Persistent Reserve In/Out Invokable by initiator,
required by targets. The next command was Log Select PC = 00
(threshold). Considerable discussion ensued. Roger Cummings was
concerned that the decisions would restrict things that have been done
historically in tapes. Dal Allan felt that the profile needed to
define a set of core values you can depend on. Doug Hagerman felt that
SCSI commands should be left out of the profile. It was decided to
drop this discussion to allow the participants time to review the
Stewart Wyatt requested that Bob review item # 16. Stewart wants to
see the error policy require discard multiple sequences. He gave an
example of a multiple sequence read that fails. He would prefer that
the error recovery restarted the transfer at the point where the
failure occurred and continue from there, overwriting sequences that
were received correctly after the failing sequence but subsequent to
error recovery. Stewart's justification for this request is that it
might require physical movement of the tape and he thought it would be
easier to more it once and continue than to move it back, read and
then move it forward. Other places in the profile do not require that
the tape start recovery at the specific relative offset of the
failure, allowing the drive the option of starting recovery at a
convenient point for the tape. Bob Snively marked the issue as
dependent on the recovery implementation specified in profile and
subject to later review.
Also in #16 Matthew Wakeley wanted ACK generation assistance
(determines ACK_0 or 1 choice) to be allowed which Bob wanted to be
prohibited. Bob marked this issue for review also.
Dave Peterson took the floor and put up a handwritten overhead with
the issues he wanted to review. These were.
1. SRR Issue
2. Remove an annex's
3. Target Reset/multi-pathing
4. State diagrams
>1. The SRR item was a review of the Error Detection and Recovery
Diagrams which Dave had previously distributed on the reflector. These
diagrams are intended for inclusion as a profile annex. Dave reviewed
each of the diagrams.
He noted some cases where the SRR was lost or the SRR Response was
lost that were indistinguishable to a host. A few corrections were
made to Dave's drawings. It was noted that in a Class 2 case either
FCP_TOV or E_D_TOV could be used. A comment was made that when an ACK
was lost for a FCP_XFER_RDY that the error recovery procedure is
unnecessary as the arrival of data is confirmation that the
FCP_XFER_RDY was received. In some diagrams, Dave was asked to remove
references to ACKS following frames other than the last one of a
sequence since the ACK_0 model is preferred. An error was noted in the
titles to several of the drawings where "Last Data Sequence" was
corrected to "Last Frame of the Sequence".
>2. The group voted unanimously to remove Annex A, B, C and D that
were duplicated from the PLDA. For Annex C Bob Snively took an action
item to describe where the IEEE Global Identifiers can be defined in a
>3. Clearing effects of SCSI Initiator Actions - Rob Bashim
Editor Dave Peterson had distributed a table defining the effect of
various clearing activities. Rob Bashim had posted an issue to the
reflector about the effects of the clearing events on multiple port
devices. Rob agreed with the table where the device is not reserved
and where the reservation and action are on the same port. The
specific issue he is concerned with is with one port getting a
resetting action when the other port is reserved. Rob was asked the
question, what happens if the port cannot be reset because of a
reservation? Several participants made comments that target reset is a
problem. The answer is not to do it.
Rob Bashim felt that there needed to be better means to control
different levels in the hierarchy to meet some of his customer
requests. There was some disagreement with this statement. The entire
loop can be reset with a LIP which is admittedly disruptive. Targets
and LUNs can be individually reset and individual initiators queues
can be aborted. It was also noted that reservations apply to a LUN,
not to a specific port. Rob felt that persistent reservations are
meaningless with the clearing action. At the conclusion of the
discussion it was recommended that Rob take the issue back to his
customers for review.
>4. State Diagrams. Dave Peterson put up an overhead with an example
of a state diagram. He comment that the state diagrams are difficult
to generate and will be difficult or impossible to finish in time to
meet the profile goals.
The group voted 14 to 1 to instruct David to not do the state diagrams
if it impacted the schedule. Bob Snively thought that if the ladder
diagrams could be collapsed because of commonality that it may be
possible to create the state diagrams without too much effort, but he
agreed with the majority that it wasn't worth slipping the schedule.
9. T10 New Business:
A. SSC Changes. The SSC was near completion but progress has stopped.
Gary Stephens, who was the editor, has not replied to requests for
information. Dave Peterson volunteered to replace Gary as editor if
needed to complete the document. Dave said he needed to know what
remains to be completed. Rob Bashim will try and get Gary Stephen's
notes. If the notes are unavailable a clean copy of rev 11 should be
printed for review. It was thought that a check should be made with
John Lohmeyer before approaching Gary. Bob Snively told Dave that the
SSC was in pretty good shape. He didn't think it would take much work
to complete it.
B. Tape Alert. Stephen Gold of HP Bristol has been trying to get "tape
alert" into the SSC. Bob Snively wanted a formal proposal and review.
Few of the members were familiar with tape alert and wanted to be
better informed before taking any action. Stewart Wyatt promised to
post the URL of the tape alert web site to the reflector. He also
thought that Stephen would be attending the FC-TAPE meeting in August
in Portsmouth and could make a presentation then. Action by the group
was deferred to next months meeting.
Posting comments on the FC-TAPE draft. A new format has been proposed
for making comments to the reflector. The proposal is 98-227v1 and the
template is 98-226v0. The format is similar to Bob Snively's comments
posted earlier. Long lists of comments need to be uploaded to the web
site with an announcement posted to the reflector to avoid the email
limitations that some systems impose on document length.
Dale LaFollette asked the group if they wanted to schedule any
additional ad hoc meetings between now and the next scheduled meeting
in Portsmouth. No one wanted to travel so it was decided to try and
resolve the issues over the reflector.
11. Review new action items:
Uncompleted from last month: Dave Baldwin: ABTS proposal.
New for this month:
1. Stewart Wyatt will update last months minutes.
2. Bob Snively will describe a standard way for obtaining document on
the IEEE global identifiers.
3. Dave Peterson will contact John Lohmeyer about editing the SSC.
4. Rob Bashim will contact Gary Stephens for a copy of his SSC notes.
5. Stewart Wyatt will post the tape alert URL to the reflector and
arrange for a tape alert presentation at next month's meeting.
6. Roger Cummings will post the location of the template for making
comments on the profile to the reflector.
7. Dale LaFollette will NOT schedule an additional ad hoc meeting.
8. Dale LaFollette will arrange to extend the time of the profile
meeting next month in Portsmouth.
9. Dale asked to have an additional action item added to the list that
he forgot to raise in the meeting. For all host providers: What
commands with which fields need to be supported in the FC-TAPE
Please note: Last month's minutes have been revised as described in this
document and uplated to the FC Home page. I do not see the need to post
them to the reflector
Stewart Wyatt stewart_wyatt at hp.com
CPB Boise Controller Group Phone: (208) 396-3594
Hewlett Packard CPB Boise, PO Box 15, MS 477, Boise, ID 83707
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10