Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt

[Brian E Carpenter <[e-mail]>]

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