RE: iSNS: Event registry and notification

[Joshua Tseng <jtseng@NishanSystems.com>]

JP,

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

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

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.

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

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

> 
> -JP
>