Proposal for IEEE company_id based formats for FC-PH world-wide identifiers

Mon Jan 6 14:37:00 PST 1997

* From the SCSI Reflector (scsi at symbios.com), posted by:
* "DeKoning, Rod" <rdekonin at ppdpost.ks.symbios.com>
*

Larry,

I do not believe that this strategy comes with a cost to the single 
controller case, nor does it make SCC mandatory.

The direction set in the July meeting allows systems to cold swap or hot 
swap a device in BOTH single and dual controller configurations and continue 
to find the volume using the one handle that remains consistent through 
these swaps - the Logical Volume WWN.

What you and Bob proposed is technically legal, I only wanted to illustrate 
why developers may not want to follow this course.

We are currently at a cross roads where it is very important that OS driver 
writers understand the primary handle to use when discovering volumes is the 
volume LUN WWN.   This is important to support both swapping and dual access 
pathing.  I believe (and the group agreed in July) that statically 
configuring a node ID to a Volume LUN ID is setting the wrong direction.

Perhaps you can enlighten me as to why it is so important to make this 
static designation instead of leaving it dynamic as previously discussed.

Best Regards,

Rod DeKoning
Symbios Logic

PS: With regards to your question concerning pg 13 of X3T11/96-467, I 
believe the statement is meant to state that for each transport flavor 
(parallel SCSI, FC-PH, 1394, etc.) you must provide an identifier that is 
appropriate.  For example, the previous sentence indicated that IEEE 1394 
normally uses the EUI-64 format,  FC-PH would use X3.203-1994.  Bob, Please 
correct me if I am misinterpreting.

 ----------
>From: scsi-owner
>To: DeKoning, Rod
>Cc: serial_solutions; scsi
>Subject: RE: Proposal for IEEE company_id based formats for
>FC-PH world-wide identifiers
>Date: Monday, January 06, 1997 1:07PM
>
>* From the SCSI Reflector (scsi at symbios.com), posted by:
>* Larry Chen <larryc at maxstrat.com>
>*
>Hi Rod,
>
>I too would like to see the multiple controller case supported by the
>industry but
>not at the expense of 1) the single controller case 2) making SCC mandatory
>for all
>RAID controllers.
>
>Note - I am neither agreeing or disagreeing with you in this email. Just
>trying to
>clarify something.
>
>Does your ideas adhere to the below statement made by document X311/96-467,
>page 13 (of 22)?
>
>While more than one device identifier may be defined for a device and while
>more
>than one object may be identified within the device, at least one of the
>identifiers
>shall be the same value and format that is used by the transport medium.
>
>In the multiple controller case, what object will be used by both the
>transport
>medium and the SCSI level? Am I interpreting the above statement 
incorrectly?
>
>Regards,
>Larry
>
>On Mon, 06 Jan 97 13:18:00 CST  DeKoning, Rod wrote:
>>
>>*
>>* From the serial_solutions Reflector, posted by:
>>* "DeKoning, Rod" <rdekonin at ppdpost.ks.symbios.com>
>>*
>>* To post to this Reflector, send email addressed to
>serial_solutions at zk3.dec.com
>>*
>>
>>
>>Larry, Mike, Bob, et.al.,
>>
>>Below, Larry discusses a mechanism to associate a controller (node) name 
to
>>a Logical Unit.  This concerns me (and possibly others?) for the following 

>>reasons.
>>
>>I went back to my personal notes for the July Serial Concerns Meeting to 
be
>>sure we had discussed this point adequately, and I believe that we covered 

>>this topic in some detail.  At that meeting, we discussed the fact that we 

>>wanted to purposely break the link between the Volume Logical Unit WWN and 

>>the Node Name of the device reporting the LUN's WWN.  This is to ensure 
that
>>we provide the following capabilities:
>>
>>1. Allow for dual controller environments in which the LUNs may be 
addressed
>>from different controllers with different node IDs.
>>2. Allow for hot swapping of devices used to access the LUNs.
>>
>>
>>In the final analysis, (at least as I recall and recorded it) we are 
trying
>>to encourage OS drivers and applications to avoid making a static link
>>between a Volume Logical Unit and the device (controller) that is used to
>>access the Volume Logical Unit.  In general the OS drivers should be
>>concerned with the WWN of the LUNs, and not the access devices since the
>>data they are concerned with is associated with the LUNs and not the 
access
>>device(s).
>>
>>Please let me know if this is not consistent with the July Serial Concerns 

>>discussion.
>>
>>Thanks,
>>Rod D
>>
>>By the way, not linking the Logical Unit to the device is a key aspect to
>>some of the changes we are proposing in the SCC2 model using the ASSIGN 
and
>>DEASSIGN commands.  These commands allow Volumes to be assigned or
>>deassigned Logical Unit Numbers to different controllers connected to the
>>same storage.  To take advantage of such a capability, the system OS must 
be
>>concerned first and foremost with the Volumes WWN, and only then, its
>>physical path.
>>
>>
>> ----------
>>>From: Larry Chen
>>>To: scsi; serial_solutions
>>>Cc: Mike Wenzel
>>>Subject: RE: Proposal for IEEE company_id based formats for
>>>FC-PH world-wide identifiers
>>>Date: Thursday, December 19, 1996 12:59PM
>>>
>>>
>>>*
>>>* From the serial_solutions Reflector, posted by:
>>>* Larry Chen <larryc at maxstrat.com>
>>>*
>>>* To post to this Reflector, send email addressed to
>>>serial_solutions at zk3.dec.com
>>>*
>>>
>>>Hi Mike,
>>>
>>>Assume the following configuration:
>>>
>>>Host Computer <----FC-AL----> RAID controller + disk drives + enclosure
>>>
>>>The host computer is attached directly to the RAID controller only
>>>(not the disk drives). The RAID controller will manage the disk drives
>>>and export virtual LUNs to the host computer.
>>>
>>>At the SCSI initiator's side and level, I wanted a mechanism to associate 

>>the
>>>virtual LUNs with its RAID controller. This mechanism would be general
>>enough
>>>to work for both the simple disk drive case and for the RAID case.
>>>
>>>Below, I will attempt to describe the entities at the FC and SCSI layers
>>>for my current configuration.
>>>
>>>At the FC transport layer
>>>-------------------------
>>>Port entity is a SIM in CAM terminology.
>>>
>>>Node entity is the RAID controller (or more specifically,
>>>        the RAID controller's Field Replaceable Unit (FRU)).
>>>
>>>
>>>At the SCSI layer
>>>-----------------
>>>LUN entity is a virtual LUN.
>>>
>>>RAID controller entity is the FRU.
>>>
>>>
>>>
>>>In my single RAID controller configuration, the FC Node entity and the
>>>SCSI RAID controller entity are equivalent (and probably will have the 
same
>>>value).
>>>
>>>Port name - any old WWN
>>>Node name - IEEE Registered Format
>>>Virtual LUN name - IEEE Registered Extended Format
>>>RAID controller name - IEEE Registered Format
>>>
>>>and the association field could be used to associate the Virtual LUNs
>>>with its RAID controller.
>>>
>>>A problem arises when multi-RAID controller complexes are introduced.
>>>Now, the RAID controller entity is ambiguous (FRU vs. the virtual
>>>RAID controller) and the FC Node entity and the SCSI RAID controller
>>>entity are probably not the same.
>>>
>>>At this point, I will not be pursuing this matter any further (unless
>>>someone is willing to stand-up with me).
>>>
>>>As an observation, RAID devices seem much more complex when compared to
>>>the simple disk drive case. I hope the RAID Industry will form some
>>>initiatives that will rectify this soon.
>>>
>>>Please call me if there are any further questions.
>>>
>>>Regards,
>>>Larry
>>>On Thu, 19 Dec 1996 11:27:42 -0800  Mike Wenzel wrote:
>>>>Hi Larry,
>>>>
>>>>I agree with a previous post, the following description is too vague to
>>>>really follow what is happening.  Could you give a scenario, including 
the
>>>>topology and node name of the controller and controlled device, then 
show
>>>>what specifically would appear on the device's Device ID INQUIRY page
>>>>(I assume that's what's involved) to correlate the devices?  If you get
>>time
>>>>to do this, please post it to the broader distribution list: I'm shure a
>>>>number of people were confused and that even more didn't really 
understand
>>>>the scheme.
>>>>
>>>>Best Regards and Seasons' Greetings,
>>>>
>>>>Mike Wenzel
>>>>mw at core.rose.hp.com
>>>>
>>>>>I was ready to go to Dallas and make a formal proposal but
>>>>>fortunately, Bob Snively mentioned that I could use the
>>>>>24-bit company_id and 36-bit Vendor Specified Identifier
>>>>>fields from the virtual LUN's WWN in IEEE registered
>>>>>extended format to get a pseudo WWN (60-bits only) for its RAID
>>>>>controller node instead.
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>----------------------------------------------------
>Larry Chen               Tel: 408.383.1600 (x116)
>MAXSTRAT Corporation     Fax: 408.383.1616
>801 Buckeye Court        E-mail: larryc at maxstrat.com
>Milpitas, CA 95035
>----------------------------------------------------
>
>
>
>
>*
>* For SCSI Reflector information, send a message with
>* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
>
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com