Hi,

Sorry about the delayed response, coming just between summer holidays where I 
live and New Year holidays where Bing lives ;-). Some comments in line.

On 18-Dec-19 23:54, Liubing (Leo) wrote:
> Hi Brian,
> 
> Thanks for the detailed review. Please see my replies inline.
> 
>> -----Original Message-----
>> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Monday, December 16, 2019 12:21 PM
>> To: Anima WG <anima@ietf.org>
>> Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt
>>
>> 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).
> 
> [Bing] Personally I'm ok with it. "PUSH" sounds more intuitive.

[Brian] OK. But I still have some questions, see later.

> 
>>>    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.
> 
> [Bing] The M_PUSH is not bind with SUBSCRIBE. It could be sent standalone. Is 
> it possible we could specify that GRASP_LISTEN_PORT MUST monitor M_PUSH as 
> well?

[Brian] Theoretically, yes, but in that case why don't we simply use M_FLOOD as 
already defined but sent to a unicast UDP destination? Obviously in this case 
there will be no flood relaying but otherwise the existing mechanisms for 
receiving a flood message can be reused. That has the advantage that M_FLOOD 
can carry more than one objective if required.

(By the way, because M_FLOOD is unacknowledged it's easy to do with UDP. 
M_REQ_SYNCH and M_SYNCH are easy to do with TCP, but UDP is more complicated 
because the messages have to be matched to the right session, which is 
automatic with TCP.)

>  
>>>    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.
> 
> [Bing] I tend to agree from practical perspective. However, I'm not very sure 
> whether it's necessary to close the little flexibility of multiple objective 
> in one message?

[Brian] As noted above, when I think about coding this, it actually seems 
simpler to copy 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.
> 
> [Bing] Exactly.
> 
>> 2) If result of the match is "discontinue" I assume the node does not cache 
>> the
>> flooded objectives.
> 
> [Bing] The text doesn't explicitly specify the cache behavior. But I share 
> the same opinion that the node does not cache when the match is "discontinue".
> 
>> 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.
> 
> [Bing] If there is matching condition in the packet, then the matching rules 
> behavior automatically be superior. So, even it is a GRASP relay, it would 
> discard the packet when match condition is "discontinue".

[Brian] OK. That needs to be stated carefully in the draft. It's a little 
complicated for the implementation, because it delays the decision to relay a 
flood until after the O_SELECTIVE_FLOOD option has been processed. (My existing 
code makes that decision much sooner, so some restructuring would be needed.)

By the way, I think you need to define where the O_SELECTIVE_FLOOD option is 
placed. For example

flood-message = [M_FLOOD, session-id, initiator, ttl,
                ?selective-flood-option,
                +[objective, (locator-option / [])]]

> The match rules don't consider whether how the neighbors would react on the 
> same rule. This might be "rude" for some scenarios, but could be efficient in 
> some specific scenarios, e.g., highly-herachycal networks.
> 
>> 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.
> 
> [Bing] Normally, the match object is the node itself. 

[Brian] OK. However, Anima doesn't really have a formal node identity, so I 
think you need to define what you mean very precisely. At the moment I don't 
know what I would write in my program for this.

> But we wanted to keep a bit programmability to allow the node to judge 
> whether to continue or discontinue the flooding based on its neighbors' 
> information.
> It assumes that the node has already learned the neighbors' info previously. 
> Let me try to make some detailed examples in the next version.
>  
>>> 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,
> 
> [Bing] You are right, we made the mistake. Thanks for pointing it out.
> 
>> 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.)
> 
> [Bing] As replied above, I believe this is a valid use case. But we wanted to 
> decouple M_PUSH and SUBSCRIBE. 
> 
>> 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.
> 
> [Bing] If M_PUSH is standalone, then UNSUB is needed.

[Brian] Agreed.

>  
>> Finally do we actually need M_PUSH, rather than just sending M_SYNCH again
>> whenever needed?
> 
> [Bing] Even if we don't need M_PUSH standalone. I think current GRASP doesn't 
> support multiple M_SYNCH for a single M_REQ_SYNCH? 
> Quoted as below from GRASP, I interpret it as "Per Sync Per Req":
> " It then sends a synchronization request (using M_REQ_SYN)
>    to the counterpart, including a specific synchronization objective.
>    The counterpart responds with a Synchronization message (M_SYNCH,
>    Section 2.8.10) containing the current value of the requested
>    synchronization objective.  No further messages are needed and the
>    transport connection SHOULD be closed. "

[Brian] Yes, that would have to change. But if we make PUSH the same as unicast 
FLOOD, this issue goes away.

>  
>>> 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?
> 
> [Bing] I think it's another mistake. The PUB option should be in the M_PUSH 
> message. Since it is per Sync per Req (if I understand it correctly).

[Brian] OK.

If you make a new version  with the changes we've discussed, I will think about 
a test implementation. 

Regards
   Brian
> 
> Many thanks again!
> 
> B.R.
> Bing
>  
>> Regards
>>    Brian Carpenter
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to