Hi Brian, Thanks for your comments! Since this new version proposed some protocol extensions, we really need review from GRASP perspective. Please see reply inline.
> -----Original Message----- > From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter > Sent: Thursday, July 12, 2018 11:15 AM > To: Anima WG <anima@ietf.org> > Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt > > Hi, > > I haven't had time to carefully read sections 1-5, but I think their general > message is fine. Here are some first comments on section 6, the proposed > GRASP extensions: > > > In fragmentary CDDL, a Un-solicited Synchronization message follows > > the pattern: > > > > unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, > > objective] > > > > 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, 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). > > Three comments on that: > > 1. For this to work, the receiving node must always be listening for a new TCP > session on that port. So that means a new API function > (listen_unsolicited?) and of course either a separate thread or an additional > entry in the event loop. Not a problem, just an implementation comment. [Bing] I believe so, another API should be needed. > 2. We need to specify that a new session_id is generated for each new > M_UNSOLDSYNCH message. [Bing] Yes, detailed behavior will be completed in the next version. > 3. Is this available for any synchronization objective, or do we need to add > a new > flag bit? [Bing] Ideally, I think the possibility should be open for any Synchronization Objective. But personally I prefer to avoid revising the base protocol as much as possible (e.g. changing the flag bits). How about we just assume any Sync Obj could be Un-solicited, would there be any harmfulness? > > The selective flood option encapsulates a match-condition option > > which represents the conditions regarding to continue or discontinue > > flood the current message. > > To be clear, the match is evaluated in every node, and the flooded objective > is > dropped if there is a match? So we save on storage, not on processing. [Bing] Yes, it's even more flexible that we can define either "something matched" or "something not matched" to let the node drop the flooded messages. Save on storage is surely one benefit, but I think maybe the more beneficial is saving on network traffic, especially in an constrained environment. And also on security benefit, that some sensitive informative won't be propagated too far. > > 6.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. > > Can it also be included in M_UNSOLDSYNCH ? (In other words, the pub/sub bus > does not need to send M_REQ_SYN, but always listens for M_UNSOLDSYNCH.) [Bing] Currently, we follow the principle that Sub/Pub should be a more strict transaction model. Un-solicited Pub seems too arbitrary. But we can leave it as an open question, let's see if we could find some scenarios that really benefited from un-solicited Pub. Btw, we actually cared more about another question regarding to Sub/Pub. From semantic perspective, we actually preferred to make Sub/Pub as new messages, rather than current objective extension. But later we thought we should utilize the base protocol as much as possible, so we chose objective extension. May I ask your opinion on this? Best regards, Bing > > > Regards > Brian > > _______________________________________________ > 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
