RE: iSNS: Event registry and notification

[Joshua Tseng <jtseng@NishanSystems.com>]

John,

Yes, this is exactly what I was trying to say.

Thanks,
Josh 
> 
> 
> Josh,
> I could be wrong here, but I think you may not have answered 
> the question
> that Rao thought he was asking.  Perhaps you should have said 
> that LUs and
> therefore LUNs are NOT managed by the iSNS and have no direct 
> bearing on
> the size of the DD.  The reason I say that is that Host z, 
> being added to a
> DD with x, and y, should not add additional DDs  so in this 
> case, even with
> 3 hosts, you still have one DD.
> 
> Now you can both tell me I am wrong and I will slink away :-^
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: hufferd@us.ibm.com
> 
> 
> Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 
> 05/08/2001 09:53:05
> AM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'Raghavendra Rao'" <jp.raghavendra@sun.com>, ips@ece.cmu.edu
> cc:
> Subject:  RE: iSNS: Event registry and notification
> 
> 
> 
> JP,
> >
> > Josh,
> >
> > >  DD's define security/access control policy.  If a new node
> > >  only had access permission to one other iSCSI node, then those
> > >  two nodes would be the only members of the DD.  A node can be
> > >  a member of multiple DD's.  If 255 devices are in the DD, that
> > >  implies that all 255 devices have permission to access each
> >
> > In my reading of the spec, my understanding was that DD 
> only provided
> > a higher level access control and security but the final
> > access control
> > is
> > actually decided by:
> >     a) Per Target's  login access control
> >     b) Target's  Logical Unit access control (i.e target
> > would only list
> > the LUs
> >         allowed for access in response to REPORT LU command)
> 
> Your a) is correct.  But by using iSNS, the target "slaves" its
> login access control policy to the iSNS.  If the target is placed
> into a DD with initiators A, B, and C by the management GUI, then
> the administrator is configuring that target for access by initiators
> A, B, and C.  The target's login access control policy would then
> be configured by the iSNS to allow that access.
> 
> b) is a function of SCSI.  iSNS and iSCSI does not get involved
> at that level.
> 
> >
> > Your clarification above seems to be saying that, if a target x, and
> > target y
> > exist inside of a DD of which initiator z is also a member, 
> then both
> > targets
> > x and y must provide login and Logical Unit access to initiator 'z'.
> 
> Yes, this is correct if initiator 'z' were placed in the same DD
> as target x and target y.
> 
> >
> > Is this correct ? If it is indeed true, then this results in
> > creation of
> > a huge number
> > of DDs even in small networks (which I hate to see) - I 
> tend to think
> > that
> > more DDs you create, more you would need to administer and more you
> > would
> > need to manage (contrary to one's expectation)
> 
> Yes, in a large storage network, there will be a large number of DDs.
> That is why we added Discovery Domain Sets (DDS) to iSNS.
> 
> Josh
> >
> > -JP
> >
> >
> 
> 
>