From: ALPHA::"smart@witsend.zk3.dec.com" 2-JUL-1996 07:32:48.53 To: serial_concerns@DEC:.zko.alpha CC: Subj: Updated minutes for 5/31/96 meeting * * From the serial_concerns Reflector, posted by: * James Smart USG * * To post to this Reflector, send email addressed to serial_concerns@zk3.dec.com * Note: The "Reply-To:" address has been modified to point to the reflector * Here's an updated copy of the minutes of the 5/31/96 conference call that corrects typos, dropped titles, etc. My apologies for any earlier inconvenience. -- James ...... Hi everyone, I've tried to put together minutes of our Friday con call the best I could from my notes. Please feel free to comment if I recalled something different than you have. I want to thank everyone for their attendance at the meeting and the manner in which everyone participated. It sure made moderating the large number of phone lines much easier and allowed us to accomplish more. Reminder: Rough summary of issues due for 6/10/96 ANSI meeting. I'm working to make sure we achieve this (I may be calling you). Next con call tentatively scheduled for Friday 6/21/96, from 1:00-5:00 EST (10:00-2:00 PST). Please contribute to the reflector. Thanks. -- James **** Minutes of **** Serial Concerns Forum Conference Call Friday May 31, 1996 1:00-5:00 EST / 10:00-2:00 PST Attendance Summary: ---------------------------------------------------------------------------- List of attendees (e.g. all those on the phone) Mark Bradley Adaptec markb@corp.adaptec.com Stillman Gates Adaptec stillman@eng.adaptec.com Norm Harris Adaptec nharris@eng.adaptec.com Larry Robinson Adaptec lwr@corp.adaptec.com Tom Coughlan Digital coughlan@star.enet.dec.com Bill Dallas Digital dallas@zk3.dec.com Glenn Everhart Digital everhart@star.enet.dec.com Dave Fairbanks Digital fairbanks@star.enet.dec.com Caroline Fleming Digital fleming@zk3.dec.com Doug Hagerman Digital hagerman@starch.shr.dec.com Jack Harwood Digital harwood@subsys.enet.dec.com Steve Malan Digital malan@@ssdevo.enet.dec.com John Meneghini Digital johnm@zk3.dec.com Charles Monia Digital monia@starch.shr.dec.com Jim Pherson Digital pherson@ssdevo.enet.dec.com James Smart Digital smart@zk3.dec.com Lenny Szubowicz Digital szubowicz@star.enet.dec.com Dal Allen ENDL dal_allan@mcimail.com Don Cleland HP cleland@cup.hp.com Noor Din HP noori@northyork.hp.com Mark Evenson HP mevenson@cup.hp.com Ron Gould HP ron@core.rose.hp.com Tom Keaveny HP tom_keaveny@hp-roseville-om2.om.hp.com Bill Martin HP wrm@epcot.rose.hp.com Kaz Nishime HP knishime@cup.hp.com Robin Purohit HP ROBIN_PUROHIT@hp-canada-om1.om.hp.com Mike Wenzel HP mw@core.rose.hp.com Giles Frazier IBM gfrazier@austin.ibm.com Kevin Quick Interphase kquick@iphase.com Kwong Fung SCO kfung@sco.com Bill Kalfakakos SCO vass@sco.com Jim Coombs Seagate jim_coomes@notes.seagate.com Guru Pangal Starcom Tech gurup@aol.com T. Ramaswami Starcom Tech rams@core.rose.hp.com Dexter Anderson Sun Dexter.Anderson@eng.sun.com Jerry Gilliam Sun jerry.gilliam@Eng.sun.com Tarl Neustaedter Sun tarl.neustaedter@East.sun.com Ashutosh A Symbios a.ashutosh@symbios.com Charles Binford Symbios cbinford@ppdpost.ks.symbios.com Rod Dekoning Symbios rod.dekoning@symbios.com Paul Edwards Unisys paul@sj.unisys.com Kathy Elliot Unisys Ken Hallam Unisys ken.hallam@mv.unisys.com Unisys All told we had 17 phone lines connected. Rumor has it that we still had 15 active lines when the meeting ended. Meeting Summary: ---------------------------------------------------------------------------- The meeting was started by brief introductions from each of the phone sites. The phone etiquette/meeting rules where then reviewed, with no additional comments. The group purpose/objectives/goals where then reviewed, with the following comments: Re: "What the objective of the con call is:" We want to emphasize systems issues. Attempts to talk to other subsystems vendors has been on a 1 by 1 personal basis and is cumbersome/difficult. It's been difficult to find a forum with the right vendors involved - and where everyone's been present at once. We do not want to focus exclusively on FC issues (although that's where most of our interests are today). Some of the problems are more generic and cut across families of interconnects. As such, they should be solved in a generic interconnect-independent form. We want to get widespread agreement on issues and resolutions. We want to avoid segmented implementations as it only hinders success for all. Re: "The goals of this effort are:" We want to be able to present recommended procedures, etc to the standards commitees. These should be able to be written up as technical reports or white papers. We want to be able to identify how an issue is being resolved, whether that be by indicating future work, ownership by another body, etc. Comments on what constitues a true issue was then requested. Several comments were fielded that included the following: "Is it an issue of lost functionality" "If not corrected, then applications (not just the drivers) are affected" "If it prevents me from buying from multiple vendors" "If it prevents me from interoperating with other vendors" It was recommended that each issue be given an importance classification, potentially based on how immediately it affects the group. Comments on what constitutes a consensus was then requested. A very brief discussion decided that as long as there was some number of constituents that believed it was an issue, it would be considered valid. As per request, we immediately reviewed 2 issues that were deemed to not be issues. Issues 16 and 24 were reviewed. Summaries of the discussions are given below. We then went through the rest of the issues list. Summaries of the discussions are given below. Finally, we reviewed the agenda for future action. Consensus was that although this many phone lines was cumbersome it did work today and saved considerable expense (in the form of travel, etc). Suggestion that we continue to meet via this forum. We need to appoint a liason with the X3T10 and X3T11 groups to present these issues as well as keep the group informed as to the actions of the standards groups. Bill Dallas or Doug Hagerman were mentioned as possible candidates. It was recommended that we try to report to the standards groups as quickly as possible so they can at least get the issues on future agendas. The issues should be reported with enough detail to convey the discussions that have gone on already (to avoid another round of discussions with the recipients). A rough regrouping of the issues, to reflect todays conversations to be completed for the June 10th X3T11 meeting. Issues to continue to be worked via the reflector, with a tentative meeting for 6/21/96. Agenda for the meeting to be developed based on reflector conversations. Noted was that the Public Loop Profile group is trying to reach consensus in order to present at the August ANSI meeting and to later table the doc sometime in October. There was a recommendation that we get the word out that this reflector exists. Post notices to the other X3T10 and X3T11 reflectors, etc. Issues Summary: ---------------------------------------------------------------------------- The general comments and resolutions for each of the issues are as follows: General Comments: It was decided that the definition of "tabled" in reference of not accepting an issue, would mean that the issue would be removed from the official list, but would be open for further discussion via the reflector. There was questions as to what documents we live by. The overwhelming feeling was that you live by the profiles. Doing otherwise will give you little latitude for interoperability. It was questioned as to what profile these system level issues would live in. The general feeling was that many of these issues would be folded into the Public Loop Profile. The tracking of issues that may be being worked in other bodies became an issue. At the end of the meeting it was decided that this group should have a liason with the ANSI groups to facilitate tracking and notification of pending work. Issue 1: Device Identification Comments: After several comments on options such as the device id page, Vital Product Data, etc that could be used, general consensus was that while all the tools exist, there was no real guidance on which one(s) to use. (note: this issue crossed out of the FC arena into SCSI-3 in general). (note: although some of the profiles called out what was required, not all the bases were covered.) Resolution: General consensus was that this was an issue. Issue 2: Topology Probing/System Configuration Comments: It was noted that different topologies may have different probing techniques. Do we really want several to coexist ? What happens when multiple topologies (where each is covered by different profiles) coexist (e.g. private and public loops). Do we expect the initiator to have multiple roles. Statement was made that we have an implication on behavior: That a public loop device, when finding itself on a private loop, must fall back to the private loop behavior. Do we have all the requirements on switches/fabrics to expect nameserver support. No. We haven't considered how reliable nameservers should be (what happens when they're not), how we propagate configuration changes across the system, etc. There was some discussion on who propagates the configuration change - the fabric or the device. Resolution: General consensus was that this was an issue. It is expected that the Public Loop Profile will cover this. However, it is noted that this profile is still under construction. Even if we come to a consensus on using a name server, we don't necessarily have all the infrastructure in place to guarantee support of this. Issue 3: Address Space Use Comments: Re: "Area and Domain" address components Issue generated by concern to maintain and provide infrastructure for a full 24 bit address space. After much discussion regarding why and where to be concerned about 24 bit addresses, the general consensus was that it was not a problem until a fabric with heterogenous switches was created. Prior to that point, it's believed that a fabric comprised of a homogenous set of switches will not have a problem and will not be too confusing. If there are separate switch vendors they will be on separate fabrics. Public loops will just happen to function such that the upper 16 bits are common for public devices on the same loop. Bottom line: the 24 bit address should be viewed as opaque and vendors should read nothing into the address components. Resolution of same device via multiple fabrics should be achieved using the unique IEEE names. This fact should be mandated by the profiles. Re: "Soft Addressing" Basic feeling was that if you achieve unique device identification via resolution of issue 1, you have achieved what's necessary for soft addressing. However, system vendors will have to convert to truly move away from device identification via the soft ids. (e.g. use the IEEE names) There was a concern for commands that are based on the soft ids (e.g. COPY, RESERVE/RELEASE). Re: "Address space assignment and adjacency" "What is adjacency" was discussed, with most coming to the consensus that following cabling was undesirable, but that it really was outside of the interconnect. System vendors will have to spec/buy the hardware that provides the desired level of discoverability. Also noted was the features that the Enclosure Services Interface (ESI) has to help address this. It was noted that the loop position map passed around at the end of the LIP process will give some help to discover adjacency on a loop. However, it was noted that legacy devices do not generate position maps. It was suggested that device enclosures may be able to play with the upper and lower bits of the hard address for the devices within the enclosure. This may enable adjacent devices in an enclosure to be id'ed adjacently. Resolution: Re: "Area and Domain" address components Covered - will be removed from the list and tabled It's a bit premature to consider heterogenous switch fabrics. Re: "Soft Addressing" Covered - will be removed from the list and tabled Action Item : affect of soft ids on commands to be further investigated. Re: "Address space assignment and adjacency" Issue exists in that legacy devices do not return the loop position map. Issue 4: Multi-Initiator issue--"Disruptive" Device Parameters Comments: Noted that SCSI specs usually cover the non-volatility of the mode pages and behavior on change, power up, etc. Interoperability between os's over the same device is desired, but not immediately relevant. However, there was dissention on this last point ("immediately relevant") as some vendors already see environments with multiple os's, and where those os's are not all from the same vendor (NT gets mixed in there). Resolution: Management of this sort is up to the OS's to manage. The OS vendors need to get together and make a proposal for a common methodology. (key on each mode page proposed). (and the group will try to get Microsoft involved with this) As such, the issue will be removed from the list, but will definitely be further discussed. Issue 5: Security/Access Control Comments: It was noted that Lansing Sloan of Lawrence Livermore National Labs presented a proposal to help deal with this. The proposal was shot down, but most were unsure why. This could use some further investigation. Question came down to where do we have this ? In the fabric ? On a frame level (discouraged) ? What level of security is defined ? (what is security by the way ?) Resolution: General consensus was that this was an issue. However, the issue is not deemed to be an immediate problem. Will treat much like issue 4 - the issue will be removed from the list, but will definitely be further discussed. Issue 6: Level of Device Intelligence--Dumb Device vs. Server? Comments: Brief request to put this in the same category as issues 4 and 5. A better understanding of these issues will be gained as the Public Loop Profile is evolved. Resolution: Issue treated the same as 4 and 5. The issue will be removed from the list but will definitely be further discussed. Issue 7: Interoperability testing Comments: Noted that this topic is primarily addressed by the University of New Hampshire FC testing effort backed by FCLC and FCA. Resolution: Issue to be removed from the list as addressed by UNH. However, request to all made to drum up more support for UNH and connecti-thons. Issue 8: Execution order of SCSI tasks by a Logical Unit Comments: Noted that execution order is not really supported by FCP. There was a feeling that the ability to control this may be needed for some devices (sequential access, cdr's, worms, etc). There were some members that vocalized that they do not recommend using tagged queuing when needing ordered execution. If you want ordered execution, use linked commands. However, linked commands are forbidden by the current profiles and give you no overlap in execution. The FC-PH resource recovery qualifiers should cover/protect most (if not all) of the concerns relative to ios bypassed by the abort task function. Noted that the current rev of the public loop profile requires in order delivery (relative to a class of service) through a fabric. Noted that frame errors or the use of multiple paths may still create out of order delivery even if the fabric is ordered. Resolution: General consensus that it may be needed for some devices. Thus the issue stands. Issue 9: In flight I/O tasks in relation to QUEUE FULL and BUSY statuses. Comments: Comment that even in SIP (parallel SCSI) this scenario can exist as there is no requirement in SIP that disallows disconnecting then reselecting and returning a BUSY status. Resolution: Given that you may need an ordered execution model for issue 8, this is an issue. Issue 10: Re-transmission of data Comments: Noted that the use of XFR_READY and unordered delivery allows FCP targets to be able to request retransmission. Noted that this doesn't extend to the FCP initiator though. Noted that X3T10 and X3T11 now looking at tapes and Fibre Channel. General feeling was that the discussion was bringing out that this was mainly a tape issue. Resolution: Tape specific issues given in this issues list will be consolidated and given to the T11 commitee. However, it was noted that in the network space, frame recovery is where most networks deal with errors. If we discard this issue now, we may find that we were premature doing so. As such, we will keep this issue on the list, but will move it to the end of the list (in an inactive state for now). Issue 11: Use of Directly Attached Tape Drives and other device types Comments: Noted that this issue is actively being discussed in the X3T10 and X3T11 forums. (My comment: I asked to have these and several following issues posted so that all on this list are aware of what is currently being discussed in front of the standards committees). Resolution: This issue will be dropped from the list as the X3T10 and X3T11 groups are addressing it. We will continue to monitor the progress of this issue in the standards groups. Issue 12: Minimizing loop disruption in case of device plugging Comments: Noted that this has been under discussion in the X3T11 commitees. The general feeling of the committee today is that this is really not a big deal. Do we agree ? Only concern was how often we expect this disruption to occur. Resolution: We will keep this issue on the list, but will move it to the bottom. We will try to track X3T10 and X3T11 for status. Issue 13: Poor documentation and understanding of global device ID scheme in the presence of dual controller and dual loop FC-AL. Comments: Most felt this was a continuation of Issue 1 and suggested that it be rolled into that issue. There were questions on subsystems with multiple controllers, do the id's stay with the controllers, the device, or with the media. Some felt that the SCC work should be addressing some of this. There was a question as to how the FC id's map and coordinate with SCC. Resolution: There was a general consensus that this was an issue. However, it will be rolled into issue 1. Issue 14: Use of OFC in Mixed Copper/Optical systems Comments: This was deemed to be primarily an interoperability issue. There may be current workarounds for this. This should be dealt with as a PH0 issue for X3T11. Resolution: This issue will be closed assuming that the X3T11 group is aware of the problem and is working it. Issue 15: Delivered Error Rates Comments: What is the actual error rate ? Many of the designs are based upon IBM research done 6-8 years ago (and much of this without the copper variants). There is concern that the standards were developed on an error rate that is not relevant today. This has also been a topic of the X3T11 group. Depending on the resolution from X3T11 on real error rates, the designs (choice of class, etc) may need little or significant redesign. Resolution: This issue is generally already being handled by the X3T11 group. However, this issue has significant implications and will not be dropped from the list. It will be placed at the end of the list in a monitoring state. Issue 16: Out order command reception and Abort and Clear Task Set operations (issued by own initiator) - Determining what was actually terminated. Comments: It was believed that the Recovery/Abort mechanisms used to terminate ambiguous exchanges (which use the recovery qualifier RRQ) should cover the identified issues. Resolution: The issue was removed from the list and tabled. Issue 17: Out order command reception and Clear Task Set operations (issued by another initiator) - Determining what was actually terminated. Comments: There generally were no additional comments on the issue. A point was brought up that reservations may induce performance problems. Resolution: General consensus that this is an issue. Issue 18: Out order command reception and Async Event Notification - Trying to track device state transitions. Comments: Suggestion made that this issue be combined into a general issue on ordering to include earlier ordering concerns. Resolution: This issue to be combined into a general ordering issue. Issue 19: System identification is unclear in the FC specifications Comments: There generally were no additional comments on the issue. Resolution: There was a general consensus that this was an issue. Issue 20: FC Link Level responses are independent of FCP. Comments: There was concern of how tightly the implementation (N_Port and FCP) would have to be to properly correct the problem. This is a general concern for all interconnects. Resolution: There was a general consensus that this was an issue. It is to be reworded to be interconnect independent. Issue 21: (Fibre Channel) Requirement to wait R_A_TOV timeout prior to sending frame after an N_Port initializes. Comments: It was noted that these timeouts can be negotiated with the fabric at login. It was noted that the public loop profile has R_A_TOV at 10 seconds rather than 120 as indicated in the issue. A suggestion was made that minimum values may go into Doug Hagerman's high availability profile being worked in the X3T10 group. Resolution: This issue was removed from the list. Issue 22: Multiple path and/or multiple-host switchover - making sure in flight ios from the "failed" path have been terminated. Comments: It was noted that E_D_TOV can be negotiated. As such, it was believed that the timeouts present can work but only concern was that we want it to be faster. Discussion then diverged into 2 areas: Reservation: It was generally felt that the standards are weak in how reservation works in dual-port and multi-path environments. It was generally felt that the lack of mandatory reservation support was an issue. There was concerns on how reservations were enforced (via port identifier or the soft ids - which may not be sufficient). Host dead but adapter still sending commands: Concern was that an adapter may still be sending commands that alter device state after a host has actually halted. Reservations could be used to help this. Third party logouts have been attempted to help with this, but there are issues as to whether you can actually use third-party logouts in dual port configurations (can't address the "other" port in a granularity that uniquely identifies it). Also, a third-party logout may logout more ports (and more protocols) than you really wanted to logout. Resolution: This issue is to be broken into 2 issues. The first to address Reservations and the second to address flailing adapters. Issue 23: Arbitrated Loop transmit fairness Comments: Was this really a configuration issue ? If your loop is 100% peaked by a couple of devices you should remove some of the devices off the loop. You have to be smart about what you configure. However, if the system is not always at this peak, and as the peak may cause other problems (upper level timeouts that expire), don't we at least want to provide the system designer with a tool to control this problem ? It was suggested that the disconnect/reconnect mode page may help with this. However, these are SCSI mode pages, and this is a FCAL issue. How do we control other protocols, etc (and what is fair for these other protocols) ? (Note: this may become a larger issue with public loops where the FL_Port is buffer large numbers of frames) Resolution: General consensus was that we should be able to manage this and this is generally a system house issue. This issue to be retained, but to have further discussion. Issue 24: Arbitrated Loop LIP and implicit logouts. Comments: Given the LIP process by which addresses are assigned on the loop, devices should be able to reaquire their previous address without being affected by the change in configuration. Bottom line - the profile specifies proper behavior. Resolution: The issue was removed from the list and tabled. ********************************************************************* To unsubscribe from this list, send mail to majordomo@zk3.dec.com or ALPHA::MAJORDOMO (from VMS) with the following text: unsubscribe serial_concerns For help with the majordomo commands, the text should be: help *********************************************************************