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