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. > > 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? > > 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? > > 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". 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. 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. > 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. " > > 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). 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
