|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Canonical TargetsJulian, > Why shouldn't we take the road of deferring the name discovery to > the specialized (iSCSI) part of a more general discovery protocol? The reason is, for a minimal, useful iSCSI configuration, we must not require any additional pieces of infrastructure beyond (Mark's term) table stakes for IP (e.g. DNS), an iSCSI initiator and an iSCSI target. Assuming we want to allow multitarget iSCSI endpoints in minimal configurations (I'm sure we do), there MUST be a way for the initiator to learn what targets are behind that endpoint from within the initiator's machine environment. The solution to this problem can't be `walk over to the target and read a bunch of numbers and type them in to the initiator'. > You don't expect the management applications to start using iSCSI for > discovery do you? Why not? When you say `management application' you seem to imply an application which would manage an arbitrary, possibly extremely large configuration (e.g. OpenView). Actual management applications range from simple to complex, and many configurations (particularly in the pilot phase that hopefully iSCSI will be entering) start very simple. I don't think anybody would argue that FCP PL-DA provided very complicated networks, yet every initiator implementation usually provided a program or something which simply spat out the WWNs (and probably the AL_PAs) for each target. Such a simple `management application' is going to be a lot like (perhaps IS) an existing SCSI control utility that can give you a list of buses, targets, LUNs, some inquiry data, and whatnot. Clearly, iSNS has nothing to say about this scenario. Are you proposing that SLP be used to supplant the existing simple directory mechanism in the iSCSI draft (and that it be mandatory to implement)? That might work. I'm not sure it makes sense, but if you think so, let's discuss it. In this case, multicast support (a typical objection to SLP) wouldn't be necessary, because you'd already know where the target is by configuration. SLP+iSCSI mechanisms would be offering the same service as the existing SendTargets but in a more ultimately scalable way. However, this proposal doesn't appear to solve any security problems. What security provisions does SLP have? Presumably the target would still authenticate the initiator in the SLP connection to ensure the initiator had rights to get the target list. That part is the same as the current proposal, so you're not saving the target any work. Steph
Home Last updated: Tue Sep 04 01:04:38 2001 6315 messages in chronological order |