Hi,
Since there were a lot of updates in this version, I read it again
from the beginning. Here are my comments.
In general I think this is useful work that the WG should consider
adopting. There is definitely a requirement for something in the
space between peer-to-peer synchronization and flooding to all
autonomic nodes. The fixed size of GRASP messages also limits
information distribution at present.
> 3.2 One-to-Many Communications
>
> Some information exchange involve an information source and multiple
> receivers. This scenario can be divided into two situations:
>
> 1) When some information are relevant to all or most of the nodes
> in the domain, the node that firstly handle the information should
> use a mechanism to propagate it to all the other nodes.
...
> 2) A more general case is that some information is only relevant
> to a specific group of nodes belonging to the same sub-domain or
> sharing the same interests.
It's probably worth mentioning that there is a tradeoff here. If some
information is relevant to 50% of nodes, it is probably cheapest to
simply flood it to all nodes. If it is relevant to only 5% of nodes,
it is probably cheapest to use a pub/sub model.
> 3.3 Requirements
...
> 3) Distributed Coordination....
...
> Obviously, purely relying
> on instant communication model is inefficient, while a scalable,
> common, yet distributed data layer, on which AFs can store and
> share information in an asynchronous way, should be a better
> choice.
This is the most interesting case (I think of it as a whiteboard, where
any ASA can read, write or erase). Doesn't it also relate to distributed
consensus mechanisms?
Can we consider the previous case (pub/sub) to be a subset of this case,
with only one node having write/erase capability?
> 5.1 GRASP for instant communications
...
> o Matching condition: "Device role=IPRAN_RSG"
>
> o Matching objective: "Neighbors"
>
> o Action: "Forward"
>
> This example means: only distributing the information to the
> neighbors who are IPRAN_RSG.
How does the node performing the distribution know which of
its neighbours have the role IPRAN_RSG? Is there a registration
process? Is it really any different than the subscribe process
in pub/sub? ("I subscribe to IPRAN_RSG information".)
> 5.2 GRASP for asynchronous communications
Once we have the previous point solved, we can model the
asynch distribution as a selective flood to the "whiteboard"
in each node.
Having said that, I want to look back in the draft at the Event Queue
described in section 4.2.1. I'm not sure that we need it as a separate
engine from the queues implied by GRASP's existing asynchronous
operations. If you model a producer or consumer as a process using
GRASP, it will naturally need to support simultaneous asynch operations
and an event queue.
I am wondering to what extent I can model this directly over GRASP as it
exists today. My main question is mentioned above: how does a node
know which of its neighbours have a given role?
(One possible answer is that *every* node sends out a local GRASP
flood at very low frequency, stating which roles it supports.
Then every node builds a cache of its neighbours' roles. I can
make that work with GRASP today.)
Regards
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
