|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI Discovery and SendTargets or Expediency vs. Planning---------------------- Forwarded by Julian Satran/Haifa/IBM on 06-06-2001 05:21 --------------------------- Julian Satran 06-06-2001 00:35 To: ips@ece.cmu.edu cc: From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning (Document link: Julian Satran - Mail) Paul, Just to be sure that I understood well your line of thought: - solution 1 is good because it is expedient (easy to do!) -future extensions should not be considered at this time (they will become expedient in their own time!) -commonality with other discovery protocols has no appeal (you do net mention it) I would like to point out that the SendTargets should not be considered as a standalone thing. It will (has to) be supported by a management infrastructure that: - has to install the names -check and invalidate them as needed etc. Should we start also adding ReceiveTargets to install the names in the targets (it very easy to add!). And how about certificates, ACLs etc (we could accommodate those too1). Julo "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com> on 05-06-2001 21:57:32 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com> To: "'Mark Bakke'" <mbakke@cisco.com>, IPS <ips@ece.cmu.edu> cc: Subject: RE: iSCSI Discovery and SendTargets Mark and NDT team, Nice write-up of your discussions. In summary I would like to strongly support the position of option 1 in your memo, which is keeping SendTargets as-is with the few minor modifications to support aggregation tags, but not much else. We do need to contain the scope of SendTargets, but removing it from the spec would be a tremendous loss of a very simply yet powerful feature. My supporting comments are as follows: 1. Keeping SendTargets basically as-is, but with the addition of aggregation tags is a very small increment over what must already be implemented for general iSCSI login, authentication and text processing. It is basically just another text command that has very wide spread utility. 2. The fact that a discovery session, where SendTargets can be performed, uses the exact same authentication and login mechanisms is a fundamental benefit of the scheme. Alternatives will require their own (albeit similar) implementations for authentication. Deploying, configuring and maintaining AAA infrastructure has always been a stumbling block for customers and complicating this with additional protocols and clients will not help matters. 3. The complication of an iterator can be avoided if we restrict the usage of SendTargets to a session on a well-known target or clearly document the potential issues of blocking a connection in an implementation. However, I would support the definition of an iterator if there is consensus. This is not a show-stopper. 4. Splitting SendTargets into multiple commands (ReportTargets and ReportPortalGroups) seems unnecessary and not relevant. I have not heard the entire discussion surrounding ReportPortalGroups, but it would seem that this information would be better reported via the MIB or at least should be made available via the MIB. Even if there is a need for such a command then it appears to be an entirely separate issue. 5. Enhancing SendTarget responses to include additional information regarding certificates or boot related information appears to be in the category of 'creeping elegance' and does not to need to be considered at this time. Facilities will be in place to establish the session needed to perform SendTargets anyway, and returning additional information that allows one to avoid using these facilities is purely an optimization. 6. An example of SendTarget's power and simplicity (as-is) is the ability to use it to create a SendTargets tree as you've described. There is really nothing that "needs" to be changed from the current scheme to support this behavior. This is a perfect example of how the very same mechanism can be used to 'scale' in environments from very small plug-and-play workgroups to a large centrally administered, highly secured, enterprises. So, from an expediency and philosophical perspective I believe we should implement SendTargets now and contain the number of proposed changes to keep it as simply as possible. We should NOT move this to another document, since it is really just another text command, but a very powerful one at that. Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+
Home Last updated: Tue Sep 04 01:04:33 2001 6315 messages in chronological order |