Re: [Anima] Review draft-ietf-anima-reference-model-04

On 27/07/2017 20:23, Artur Hecker wrote:
> Brian,
> 
> 
> Thanks for your answer. Good to know that GRASP takes those precautions, very good. It would be interesting to know how it does it - we will probably get to testing the current implementation at one point, please bear with us :-)
> 
> Still, referring to the draft in the email subject, as it is a reference model with requirements only, if I read it stupidly (letter by letter) then GRASP is not flooding, so it's not conforming to the reference model :-) (depending on the interpretation of "flooding" in the text).

1) The objectives in GRASP M_FLOOD (or M_DISCOVERY) messages carry a loop count that
decreases at each hop, with a suggested default initial value of 6, but of course that
might be larger in a large network.

2) Nodes that relay M_FLOOD or (M_DISCOVERY) must cache the session ID and must
not relay messages with the same cached session ID again (within the cache lifetime,
obviously).

3) Nodes must limit the rate of relaying. (This is not implemented in my
prototype, due to laziness. But the two previous points are enough to prevent
loops in any topology.)

> My actual point is that we should not get into implementations in this draft. Maybe I am wrong. I think some rewording will do the trick.

Agreed.

    Brian

> 
> 
> Regards
> Artur
> 
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
> Sent: 26 July 2017 22:14
> To: Artur Hecker; anima@ietf.org
> Subject: Re: [Anima] Review draft-ietf-anima-reference-model-04
> 
> Artur,
> 
> Thanks for your review. Whoever takes up the editing pen next will certainly use your comments.
> 
> On one specific point:
> 
>> c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference between the requirement to reach all recipients (indeed, the current text seems to equal flooding to that) and flooding, which technically usually means "unconstrained broadcast". [E.g. Wikipedia: "Flooding is a simple computer network routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on"]. This will lead to explosive message number growth, as the ACP uses routing - which does not guarantee a tree structure - while the scale of an autonomic domain is, by definitions of RFC7575, only constrained by the Intent as such ("the autonomic domain is the set of nodes, to which the intent needs to be sent"). At the same time, there are better known algorithms for routing, which achieve "distribution to all recipients" without "sending on 
>  all links except the one it arrived on" (e.g. structured broadcast, etc).
> 
> I agree in general; the way the text uses "flood" is careless. However, the GRASP flooding mechanism is (a) of course limited to GRASP nodes and (b) contains specific measures to prune the distribution and prevent loops. While that does not guarantee a strict tree structure, i.e. is not an idealised multicast routing algorithm, it doesn't require the ACP to support multicast routing and it is well adapted to low-frequency information distribution as we expect in an AN. 
> 
> Regards
>    Brian
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 