Subject: iSNS: Event registry and notification

From: Raghavendra Rao <[email-masked]>
Date: Thu, 03 May 2001 20:57:49 -0700

In reviewing -02 spec of iSNS,  the event registration and notification
need
more work to live up to the promise (and requirement of Naming and
discovery spec) of being lightweight. Right now, it defines catch-all
and receive-all events.

To start with, an iSCSI initiator MUST be able to register

 a) for state changes of specific/interested iSCSI targets.

 b) for addition of iSCSI targets that provide Login access control
    to this iSCSI initiator

Along similar lines, it would also help to provide an iSCSI target the
ability to register for an event when an iSCSI initiator is
added/removed
to the login control list of this iSCSI target. An iSCSI target, upon
receiving such a notification, can then simply download the updated
list of allowed iSCSI initiators.

Such types of notifications help reduce notification storms by
 - Helping a small iSCSI initiator client receive and process
   absolutely required notification (Note that totally turning
   off notification is a BAD idea)

 - Reducing needless traffic.

-JP

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 4 May 2001 09:41:48 -0700

Raghavendra,

Although the type (initiator or target) of iSNS client is stored
in the iSNS database, note that the iSNS server does not make a
distinction in how it interacts with each type of client--both types 
(initiators and targets) are uniformly treated as iSNS clients.
That means both initiators and targets can register for notification
and are members of Discovery Domains.
 
>  b) for addition of iSCSI targets that provide Login access control

Please review the section on Discovery Domains.  DD's are used to
define event registration and notification policy.  If you still think
more clarification is needed, let me know what is not clear.

> list of allowed iSCSI initiators.

Yes, of course.  This is the expected behavior of a target that
subordinates its login control policy to the iSNS.

>  - Reducing needless traffic.

Discovery Domains are the mechanism used to reduce/eliminate
notification storms.

Regards,
Josh

---

From: Raghavendra Rao <[email-masked]>
Date: Sat, 05 May 2001 02:20:12 -0700

Josh,

> and are members of Discovery Domains.

I understand the philosophy, my example questions based on initiator
or  targets weren't implied to change iSNS to be initiator or target
oriented, rather I tried to illustrate what one would want to get out
of the events.

> define event registration and notification policy.

Well, DDs may solve flooding of events to all unnecessary iSCSI nodes
to some extent. But I still visualise DDs to contain a good number of
iSCSI nodes even though the number won't be huge. In that case, it may
not be correct to assume that all iSCSI nodes are capable of heavyweight

processing of all kinds of events in the discovery domain - Turning off
events might be an option for those nodes but these Nodes might still
be interested in receiving notification about certain Nodes inside of
a discovery domain, not ALL of the nodes in the DD.

So what I would like to see is:

    a) more fine grained list of events
        -  One such example event would be to notify when an iSCSI node
           with certain attributes (such as access permision to a
specific iSCSI
           node)  or capabilities is added /removed to/from a  Disocvery
domain.
           Otherwise, let us say, if there are 255 iSCSI nodes in a
discovery
           domain, and if a new node is added, and even if the new node
has
           access permission to ONLY one iSCSI node in the discovery
domain,
           we would see all 255 nodes receiving notification and all 255
nodes
           probing for access control which might cause needless storm
of activity
           in the network.

    b) mechanism to selectively receive one or more (set) of these
events
       as a certain iSCSI node may not be interested in all that happens
inside
       a DD, however small a DD might be.

-JP

---

From: Joshua Tseng <[email-masked]>
Date: Sun, 6 May 2001 22:02:23 -0700

JP,

<Snip...snip> 
> a discovery domain, not ALL of the nodes in the DD.
Registration for notification is optional.  If an iSCSI device
is afraid of being deluged by notification messages, then perhaps
it shouldn't register for notifications, and instead periodically
query to get an update on DD membership.

>            probing for access control which might cause needless storm

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
other.  Initiators would therefore see and receive access to
all targets and initiators in the common DD, although in practice
they would ignore info on the initiators.

>        a DD, however small a DD might be.

We have to keep the protocol simple.  Notification is for all
events in the DD, or else you turn notification off and have the
node periodically query to re-synch with the iSNS server.

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Sun, 6 May 2001 22:11:00 -0700

JP,

One thing I forgot to mention until after I sent this
message is that there is an "SCN Bitmap" which allows
the iSNS client to register for specific events.  If
it is only interested in devices being added, but doesn't
care if devices are pulled, then it sets the appropriate
bits of the SCN bitmap.  This may help it to keep from
being deluged by notifications that it doesn't care about.
See section 6.4.4.

Josh

-----Original Message-----
From: Joshua Tseng 
Sent: Sunday, May 06, 2001 10:02 PM
To: 'Raghavendra Rao'; [email-masked]
Subject: RE: iSNS: Event registry and notification

JP,

<Snip...snip> 

Josh

---

From: Raghavendra Rao <[email-masked]>
Date: Tue, 08 May 2001 04:11:48 -0700

Josh,

>  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 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'.

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)

-JP

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 8 May 2001 09:53:05 -0700

JP,
>         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.

> 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.

> 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

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 8 May 2001 13:13:13 -0700

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: [email-masked]
> 
> 
> Joshua Tseng <[email-masked]>@ece.cmu.edu on 
> 05/08/2001 09:53:05
> AM
> 
> Sent by:  [email-masked]
> 
> 
> To:   "'Raghavendra Rao'" <[email-masked]>, [email-masked]
> cc:

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 8 May 2001 13:09:03 -0700

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.

.
.
.
John L. Hufferd

Joshua Tseng <[email-masked]>@ece.cmu.edu on 05/08/2001 09:53:05
AM

JP,

Josh