On 24/09/2017 08:43, Michael Richardson wrote: > > Brian E Carpenter <[email protected]> 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
