Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

[Brian E Carpenter <[e-mail]>]

On 24/09/2017 08:43, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >> That way, the recipient can compare sender-ttl with the TTL of the received objective
>     >> and threeby figue out which one is closest.
>     >>
>     >> I fine either way. I just tried to go for the most simple, logical option.
> 
>     > Right, so the question for the WG (are you all listening?) is whether we
>     > want to defend the value of the loop count in limiting propagation of multicast
>     > messages. (Remember that it has another role in negotiation sessions, where
>     > it really is a loop-prevention counter.)
> 
>     > I will note that in testing on looped topologies I have seen looped multicasts
>     > dropped because of the session ID; theoretically that is sufficient, and the
>     > loop count is logically redundant.
> 
> So, this lets one
>     a) notice if the M_FLOOD is forged because the TTL of the underlying
>        packet does not agree.
>     b) figure out which M_FLOOD is closer.
> 
> Given:
>     We have ACP built with P2P tunnels between nodes, and on top of
>     that we run RPL to form a *unicast* routing topology.
> 
> Should a GRASP deamon send M_FLOODs to all P2P tunnels, regardless of whether
> they are active RPL routes?    I would tend to say *YES*.

In practice, I think GRASP will send to all the ACP interfaces flagged
as active in the adjacency table. But that amounts to the same thing.

> Given that, one will expect to see the same M_FLOOD from the same sender via
> multiple paths.  That's fine, and I think it's good.  But, comparing them is
> kind of meaningless, because once you find out who the sender is, the unicast
> routing takes over, and you will take the unicast direction only.
> If one hears announcements from multiple senders, then there might be
> different directions, but the TTL you see in the M_FLOOD may have NOTHING to
> do with what the unicast cost is.

True, in a general topology - the LL multicasts combined with GRASP relaying
will ammount to a spanning tree rooted at the M_FLOOD sender, but the unicast
paths will be set by RPL. There's no reason they will be congruent. They might
be. This is a good point!

   Brian