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*.
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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
