RE: iSCSI: Send Targets and Report Portal Groups

["Douglas Otis" <dotis@sanlight.net>]

Marjorie,

This leads to feature creep where eventually all management is placed upon
the transport.  Any such management at this point will still need to come
from some other management scheme or this does not allow for promulgation or
coherency and will lead to vendor unique solutions.  I would be in favor of
removing as much away from the transport and instead converge on an existing
management server.  I would hope the signaling desired could be done by
those entities that either identify or instrument a change and then those
entities signal effected servers of these changes.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> KRUEGER,MARJORIE (HP-Roseville,ex1)
> Sent: Thursday, June 07, 2001 3:26 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: Send Targets and Report Portal Groups
>
>
> > Reasons for not having it (others can add to this list):
> > 1) Do not want discovery mechanism as part of the protocol.
> > 2) It will continue to evolve and is not as simple as it seems.
> > 3) IETF standards approving body will have a problem with it,
> > and this will
> > delay the approval of the whole standard.
> > 4) Can use SLP or iSNS to get the same functionality, and we
> > can piggyback
> > on the future enhancements to these discovery protocols.
>
> 5)There is also the viewpoint that a transport protocol should
> contain only
> what's necessary for establishing a transport link and keeping that link
> functioning.  (eg, TCP connection establishment, SYN exchange) Any other
> configuration data exchange is a management function that should use a
> generic data exchange/mgmt protocol (SLP? DHCP? SNMP? XML?).  Or iSNS.
> Given this purist viewpoint, there is a clear difference between the other
> text commands in iSCSI and the SendTargets or ReportPortalGroups text
> commands.
>
> IMO, it's a judgement call where you draw the line between architectural
> purity and practical functional encapsulation.  My current
> feeling is that a
> limited SendTargets function adds a small amount of implementation burden
> and a large amount of functional value to product solutions.  Given the
> nature and deployment of storage devices, the reporting of minimal 'iSCSI
> connectivity information' in the iSCSI protocol enables a powerful
> capability for 'plug-n-play' at a minimal cost.  The fact that
> SLP and iSCSI
> have different authentication models and points of control is a
> large factor
> in support of SendTargets - authentication management is a huge burden for
> customers.  (Of course that fact could start a whole nother thread cause
> this is a common problem between various IP-based protocols).
>
> ReportPortalGroups feels like feature-creep to me given that it's a subset
> of SendTargets.
>
> I agree with Mallikarjun, moving SendTargets to an 'annex' doesn't seem
> appropriate when viewed thru his logic, and we should strip out fluff like
> "TargetAlias", which is clearly 'value-add' more appropriate to a MIB or
> some other management interface.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>