FCP-4: Letter Ballot Comment HPQ-219

Bob.Nixon at emulex.com Bob.Nixon at emulex.com
Tue Nov 2 12:32:30 PDT 2010


* From the T10 Reflector (t10 at t10.org), posted by:
* <Bob.Nixon at Emulex.Com>
*
Hi, Ralph, the difficulty with the "shall" that I raised is not just to FCP
implementations, but to likely established usage of the Platform Name.
Platforms as originally specified were simply a Platform Name and a list of
node names. Although deriving a Platform Name from an established form of
identifier was considered, so also was administrative assignment of
human-meaningful text strings. This is still supported, and I would guess
that the majority of existing use of Platform Names would be of the character
"Engineering_Server_2" or "Building B Storage System". Unconditionally
overriding these by a SCSI device name would be a very unfriendly act.
Likewise, since Platform Names are less constrained by specification than
SCSI device names, it would be impossible to unconditionally set the SCSI
device name to match an existing Platform Name. Finally, the specified scope
of a Platform is at least as vague as that of a node, so existing usage may
not match the expected scope !
 of a SCSI device name. Thus, my resistance to "shall".
As I said originally, I see potential value in the idea, but "should" is the
most I would find acceptable in the foreseeable future.
   - bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Friday, October 29, 2010 3:54 PM
To: t10 at t10.org
Subject: Re: FCP-4: Letter Ballot Comment HPQ-219
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Fred,
Would a reminder that the FCP-4 group plans to request a second Letter
Ballot do anything to calm your fears about a late-breaking shall?
All the best,
.Ralph
On 10/29/2010 1:55 PM, Knight, Frederick wrote:
>
> I tend to agree that it's pretty late for a new SHALL.
>
> Fred Knight
>
> *From:*Bob.Nixon at emulex.com [mailto:Bob.Nixon at emulex.com]
> *Sent:* Thursday, October 28, 2010 5:17 PM
> *To:* dpeterso at brocade.com; t10 at t10.org
> *Subject:* RE: FCP-4: Letter Ballot Comment HPQ-219
>
> In the first added paragraph, "...the Platform Name shall be the same as 
> the SCSI device name" raises a good idea, but adds a new "shall" too 
> late in the game for my taste. Platform Name has never been mentioned 
> in FCP before. I would be happy with a "should".
>
> The long discussion of names reported by virtualized OSs leaves me 
> confused on a couple points:
>
> 1.It specifically relates to names "reported through all the SCSI 
> initiator ports". A Target has a VPD page, but how does an initiator 
> report its name?
>
> 2.Is there a change being suggested for FCP-4?
>
> -bob
>
> *From:*owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of 
> *David Peterson
> *Sent:* Thursday, October 28, 2010 1:18 PM
> *To:* t10 at t10.org
> *Subject:* FCP-4: Letter Ballot Comment HPQ-219
>
> HPQ-219 states:
>
> At 9.93 in down and 0.41 in over
> Add:
> "Each FCP device should include a SCSI device name in NAA IEEE 
> Registered format (see SPC-4). If the FCP device includes a Platform 
> Name (see FC-GS-6), then the Platform Name shall be the same as the 
> SCSI device name.
>
> In the Device Identification VPD page, a device server in an FCP 
> target device that implements a SCSI device name:
> a) shall report the SCSI device name in binary NAA format; and
> b) should report the SCSI device name in SCSI name string format 
> (e.g., "naa." followed by 16 hexadecimal digits followed by 4 ASCII 
> null characters)."
>
> Also add this to the SAM-5 names & identifiers annex (IEEE Registered 
> format, 8 bytes).
>
> SAM-4 allows a transport protocol to mandate implementing device names 
> and define their format.
>
> Node names were never well defined in FC, always unclear whether they 
> named a Port, an HBA (a set of Ports on the same card), or a system 
> (set of cards in a system). They are thus worthless.
>
> Platform name supposedly provides clearer guidance, identifying the 
> entire system - the same scope as a SCSI device name.
>
> With NPIV and server virtualization gaining popularity, it would be 
> helpful to have a unique identifier for each operating system 
> instance, reported through all the SCSI initiator ports (whether NPIV 
> or physical) that the operating system uses. If the operating system 
> instance is shut down and restarted on a different physical machine, 
> that identifier should move with it. This identifier should even work 
> if the operating system has access to a mix of protocols - e.g. some 
> FCP ports, some iSCSI ports, and some SAS ports. The same NAA IEEE 
> Registered identifier can be reported and used in FCP (both binary and 
> as a "naa." string) , SAS (both binary and as a "naa." string) and 
> iSCSI (as a "naa." string). A system that doesn't have iSCSI ports 
> could just report the binary NAA format.
>
> The device name would be helpful for configuring V-SANs, zoning, SCSI 
> access controls, etc. For example, the system administrator could 
> grant certain zoning permissions to an operating system instance, no 
> matter which physical machine it happens to be running on and which 
> ports it happens to be using.
>
> I have no problem with adding accepting this comment. Please respond 
> with any objections along with your reasoning asap.
>
> Note I plan to move to accept the letter ballot comments at November 
> T10 and will have the comments and draft standard uploaded shortly. 
> There will be one comment open from my perspective and that comment is 
> on the CAP agenda.
>
> Also please consider the need/desire for a second letter ballot on FCP-4.
>
> Thanks...Dave
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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 mailing list