Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt
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 >> 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
Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt
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 > 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-object
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). >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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
