FC-TAPE July 1998 Minutes

Stewart Wyatt 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          
           98-363v0.pdf
     
     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 
     customary.
     
     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 
     noted: 
     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 
     hoc meeting.
     
     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 
     meetings.
     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 
     attendance.
     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 
     meeting.
     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 
     was opposed.
     
     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 
     tape discussion.
     
     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.
     
     6. FCP-CONF 
     Neil Wanamaker took the stand to discuss FCP_CONF. He put up an 
     overhead that contained the following text:
     
     FCP_CONF
     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 
     not.
     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.
     #37
     Command linking prohibited - 10 voted yes, no one was opposed.
     #43
     Class independent single profile - previously agreed to.
     #46
     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 
     recommendations.
     
     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 
     standard manner
     
     >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 
     profile?
     
     12. Adjournment

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 mailing list