Hi, I think this is a useful extension of the basic autonomic infrastructure. Here are some comments and questions on the GRASP part of the draft. I'd be interested in the authors' comments.
> 5.1 Realizing Instant P2P Transmission > > This could be a new message in GRASP. In fragmentary CDDL, an Un- > solicited Synchronization message follows the pattern: > > unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, > objective] I suggest simply calling this M_PUSH (but see later comments). > A node MAY actively send a unicast Un-solicited Synchronization > message with the Synchronization data, to another node. This MAY be > sent to port GRASP_LISTEN_PORT at the destination address, That port is normally tied up with multicast reception. But since we have a SUBSCRIBE mechanism below, the question of the port can be resolved at SUBSCRIBE time. There must be a listener process for this port, of course. > which > might be obtained by GRASP Discovery or other possible ways. The > synchronization data are in the form of GRASP Option(s) for specific > synchronization objective(s). One objective per message is much simpler to implement. If not, this becomes more like a "unicast Flood". If you want that, we could define the syntax precisely like M_FLOOD. > 5.2 Realizing Instant Selective Flooding > > Since normal flooding is already supported by GRASP, this section > only defines the selective flooding extension. .... > The action means, when the match rule applies, the current device > just continues flood or discontinues. Please remember that a normal M_FLOOD has two aspects for a node that receives it. First, the node stores the objectives delivered in its own flood cache. Second, *if* it is a relay node (with interfaces to more than one link within the AN, such as a router) it relays a copy of the M_FLOOD to its AN neighbors, subject to anti-looping rules. 1) If the result of the match is "continue" I assume that the node does exactly what it does with a normal flood, i.e. caches the received objectives and if it is a relay, it relays the flood to its neighbors. 2) If result of the match is "discontinue" I assume the node does not cache the flooded objectives. 2) If result of the match is "discontinue" and the node is also a GRASP relay, what does the node do? Discard or relay? It cannot know the result of the match in its neighbors. I really don't understand the meaning of the matching rules, especially "match-object = NEIGHBOR / SELF". I think this needs a lot more explanation and some more detailed examples. > 5.3 Realizing Subscription as An Event > > In fragmentary CDDL, a Subscription Objective Option follows the > pattern: > > subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] > objective-name = SUBSCRIPTION > > objective-flags = 2 > > loop-count = 2 > > subobj = text > > > This option MAY be included in GRASP M_Synchronization, when > included, it means this message is for a subscription to a specific > object. The M_SYNCH message is the reply from a data source to a data destination, so I think that's wrong. I think that SUBSCRIPTION should be used in M_REQ_SYN, when a node first wants to get the value of a given objective but also wants to subscribe to future push updates. So the reply to a M_REQ_SYN with a SUBSCRIPTION option would be M_SYNCH with an initial value for the objective, but the session could stay open with M_PUSH to follow at any time. (So that solves the question of the port: whatever port is used for sending the M_REQ_SYN listens for the M_PUSH messages.) A new M_REQ_SYN would also be used to carry UNSUBSCRIBE. Alternatively, the node could simply close the port and the next M_PUSH would fail. If we did that, UNSUBSCRIBE would not be needed. Finally do we actually need M_PUSH, rather than just sending M_SYNCH again whenever needed? > 5.5 Publishing Objective Option > > In fragmentary CDDL, a Publish Objective Option follows the pattern: > > publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name > = PUBLISH > objective-flags = 2 > loop-count = 2 > pubobj = text > > This option MAY be included in GRASP M_Synchronization, when > included, it means this message is for a publish of a specific object > data. I don't understand this. An M_SYNCH by definition delivers the current value of an objective. Why do we need to say that we're publishing it? Regards Brian Carpenter _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
