Re: iSCSI: proposal to solve the ISID issues

["Mallikarjun C." <cbm@rose.hp.com>]

Jim,

Thanks for the excellent summary.  Some questions/comments -

- I assume that the NICs must enable the configuration of 
  iSCSI Node name even in this proposal.  If it is so, please
  call this out as a hard requirement in the main modelling
  discussion.

- In the case of multiple NICs from the same vendor operating
  in an end node, it appears to me that the proposal implicitly
  assumes an ISID-range to be configurable among those NICs
  (perhaps in vendor-unique ways, which is always what I expected).  
  If this is a correct inference, there is again a hard 
  requirement on the NICs to make the ISID range configurable.  
  Please comment on any subtle qualitative change from the 
  earlier situation that I may be missing.
   
> (2-e) Its debatable whether "conservative reuse" is a MUST or a
> SHOULD.  My personal opinion is "SHOULD", because many systems,
> particularly low-end that don't use reservations, can function more or
> less OK without it.

It seems we're attempting to set ourselves up for future in 
discussing the above requirement.  Some questions - 
        - It appears to me that the "conservative reuse" can not
          be enforced for initiators hosting NICs from different
          vendors (since the proposal allows ISID namespaces to 
          be totally non-overlapping between non-homogenous NICs).
          Is this a fair assessment?  
	- Do you see a particular disadvantage for low-end systems 
          if it's mandated (aside from the fact that they may be able
          to live without it)?
	- Do you see any corner cases not being met (for future)
          if we don't make it a MUST (since you said "more or less OK")?

Regards.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


Jim Hafner wrote:
> 
> Folks, (David Black in particular).
> 
> Apologies for the long note, but the issue is complicated.
> 
> The NDTeam have a proposal to resolve the concerns surrounding use of
> ISIDs as essential components (along with iSCSI Initiator Name) of
> SCSI Initiator Portname.  (This was rooted in private discussions
> between John Hufferd, Julian and myself -- and came about as a result
> of the lengthy (and boring) discussions mostly myself and David
> Black.)
> 
> There are two somewhat orthogonal issues involved in this discussion:
> 
> 1) How to coordinate ISIDs in the initiator to minimize the risk of
> accidentally breaking the ISID RULE (no parallel nexus) when
> independent vendors co-exist in the same OS.
> 
> 2) What ISID "reuse" rules should be specified to facilitate current
> and future (soon?) SCSI reservation semantics (and also internal OS
> views of SCSI Initiator Ports).
> 
> To address these two issues, we (NDT) propose the following:
> 
> 1) Enlarge the ISID field in the Login Request and Response to 6bytes
> and structure it with a component that corresponds to a "naming
> authority" (essentially the vendor generating the ISID).  So vendors
> each have a piece of the ISID namespace to work with their own
> components (HBAs, SW, etc). More details below.
> 
> 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as
> conservatively as possible ("conservative reuse").  What this means is
> that a given ISID should be reused for as many sessions (across
> multiple target portal groups) as possible (but never to the same
> target portal group twice -- that's the ISID RULE).
> 
> NOTES and ADVANTAGES:
> 
> (1-a) Each vendor owns his own piece of the ISID namespace, so in
> effect, at the vendor-level, this provides a "partitioning" of that
> namespace.
> 
> (1-b) We don't need to specify an OS infrastructure requirement for
> configuration of ISIDs -- each vendor can do it any way it chooses
> (within its naming authority).
> 
> (1-c) Breaking of the ISID RULE will only occur if a vendor messes up
> its own implementation.
> 
> (1-d) This is not fundamentally different from David Black's
> suggestion for a "key"; it just (a) defines it precisely and (b)
> embeds it in an already defined (but enlarged) field.
> 
> (1-e) Looking towards the future, as common ISID coordination
> mechanisms are implemented between vendors (say, SNIA banding together
> to define a precise API), this "naming authority" can be elevated to
> the coordinating entity or even the OS vendor.
> 
> (1-f) ISIDs have no global uniqueness property.  They need only be
> unique between a named iSCSI initiator and iSCSI target portal group.
> That means that a vendor implementation can use the same algorithm to
> generate ISIDs (under its naming authority) in every machine (OS).
> 
> (2-a) If a SCSI target (or logical unit) is holding state (say
> persistent reservation) for a SCSI Initiator Port (named by iSCSI Name
> and ISID), and the associated nexus/session is dropped for some
> reason, "reuse" by that initiator of that ISID will restore to the
> resulting new session that state (with no other action on the part of
> the upper SCSI layers).
> 
> (2-b) "Reuse" of an ISID on different sessions to (necessarily)
> different SCSI Target Ports (iSCSI Target portal groups), will enable
> the SCSI target/logical unit to recognize a common SCSI Initiator Port
> for those two paths.  This facilitates future changes to SCSI
> reservations (at least).
> 
> (2-c) An initiator driver implementated with "conservative reuse" can
> present to the OS a stable and fairly static view of the SCSI
> Initiator Ports (one for each ISID).  Current OS driver stacks
> (including current wedge drivers) that are built on the presumption of
> such a stable view, will not need modification to handle the more
> dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of
> a SCSI Initiator Port presented to the OS does not *require* that this
> port discover all possible targets; what the initiator builds sessions
> to using a specific ISID will determine what is presented to the OS as
> "devices" and LUs visible to that SCSI Initiator Port (could be none
> if that ISID is never actually used!).]
> 
> (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator
> Port is as simple as configuring another ISID!
> 
> (2-e) Its debatable whether "conservative reuse" is a MUST or a
> SHOULD.  My personal opinion is "SHOULD", because many systems,
> particularly low-end that don't use reservations, can function more or
> less OK without it.  This is an open question.
> 
> DETAILS:
> 
> 1) ISID Structure:
> The 6byte ISID structure would be split into three parts:
>    "type" field (1byte) -- identifies the format of the naming
>                            authority field
>    "naming authority" field (3bytes) -- identifies the vendor (or
>                            group of vendors) generating this ISID
>    "qualifier" (2bytes) -- the free-space for ISID uniqueness
> 
> The type field takes on three defined values with all other values
> reserved:
>          Type    naming authority format
>          00h     IEEE OUI
>          01h     IANA Enterprise Number (EN)
>          02h     "Random"
> 
> The first types two provide a mechanism to uniquely (world wide)
> identify the naming authority.  A vendor with one or more OUIs and
> possibly also Enterprise number MUST use at least one of these numbers
> when it generates ISIDs.
> 
> The "Random" type is for the case where the ISID generator (SW or HW)
> is provided by an entity that has no OUI or EN.  This includes, for
> example,
> -- a user-written program that builds sessions (and has access to the
> system level iSCSI Name)
> -- a university or other organization providing the component
> -- a testing tool
> 
> For the "Random" type, the naming authority field should be a random
> or pseudo-random number. (See below on how this affects "conservative
> reuse").
> 
> [Note: the "type" field needn't be this big, but NDT felt that (a)
> 2bits was insufficient for the future, (b) the "type" field should be
> first, and (c) the "naming authority" field should be byte-aligned.]
> 
> 2) Conservative Reuse
> 
> The "conservative reuse" principle of this proposal just says that
> SCSI Initiator Portnames should be viewed as static things (as much as
> possible) and reused (when feasible) to give the most stable
> presentation of SCSI Initiator Ports to both the OS above and to SCSU
> targets across the wire.
> 
> Whereas the current draft says "The ISID RULE does not preclude the
> use of the same ISID to different Target portal groups", the
> "conservative reuse" requirement would say that such reuse (using the
> same ISID to many target portal groups) is a SHOULD (or is that
> MUST?).  So, in one implementation, each iSCSI Initiator Portal group
> would get configured with iSCSI Name, and a (small) set of ISIDs.  The
> portal group might take this set of ISIDs as an ordered list.  The
> first session to a Target portal group would use the first ISID, the
> second to the *same* target portal group would use the second in the
> list, etc.  The number of ISIDs would then define a configuration
> parameter that can be interpreted as the maximum number of sessions
> that can be built to a given target portal group.
> 
> To facilitate "conservative reuse", the "qualifier" field of a set of
> ISIDs SHOULD be generated using either a repeatable algorithm
> (non-random or pseudo-random but based on a fixed seed) or any
> algorithm and stored in a persistent location (e.g., registry or /etc
> file).
> 
> For the "Random" type, "conservative reuse" may not be an issue (say,
> user application that doesn't care about reservations, etc.).  When it
> is, the "naming authority" field SHOULD also be generated by a
> mechanism similar to that for the "qualifier" field as specified above
> (e.g., defined in the SW at compilation time.)
> 
> DOCUMENTATING CHANGES:
> 
> The iscsi drafts would need the following minor changes to support
> this proposal:
> 
> NDT doc
> (a) define the structure of the ISID field (as described above)
> (b) add some notes about implementation in the presense of
> "conservative reuse" (e.g., that ISID should be configured once, say
> at install time, then reused on subsequent reboots, even for "Random"
> type).
> 
> iSCSI MAIN doc:
> (a) move the CID field in Login Request to another reserved field.
> (b) expand the ISID field in Login Request and Response to encompass
> the previous 4 bytes.
> (c) add a sentence where the ISID field is defined indicating that
> this field is a structured value, showing the structure (as above) and
> point to the NDT document.
> (d) add some text to "Note to Implementors" on "conservative reuse".
> 
> Comments?
> 
> Jim Hafner