Subject: [Anima] GRASP issue 46

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jan 2016 13:49:29 +1300

>    o  46.  The 'initiator' field in DISCOVER, RESPONSE and FLOOD
>       messages is intended to assist in loop prevention.  However, we
>       also have the loop count for that.  It would be simpler to remove
>       the initiator, making message parsing more uniform.  Is that OK?

We added this in version -02 in response to Joel Halpern's observation
that a session_id might (with very low probability) be ambiguous, so it
needs to be associated with the address of the node that created it.

That remains true. However, the 'initiator' field only matters for disambiguating
multicast Discovery messages that have been relayed between LANs, so that responses
go back to the correct host in the end. In all other cases, the node that receives
a message and needs to make use of the session_id automatically knows who sent
the message.

When debugging my code for relaying Discovery and Flood messages, I realised that
I could make this problem go away very simply: by creating a *new* Discovery or Flood
message with a new session_id. For example, if A says discover("C") and this is
received by relay B, then B says discover("C") on its other interface, waits for
the response, caches it, and then responds to A with a Divert option. The two
discovery processes are independent. Not only does it solve the problem above,
it's also simpler to code.

  Node A
  __|____________________
                    |
                  Node B
              ______|___________________
                             |
                           Node C

If the WG agrees, the fix would be:

1. Abolish the 'initiator' field in DISCOVER, RESPONSE and FLOOD.
2. Change the descriptions of the relay actions (for Discover and Flood)
to require that the relayed messages have a *new* session_id. But they
still decrement the loop count.
3. Simplify the loop detection text.

My prototype code works this way and it works well. I've tested loop
prevention using the loop count mechanism, and it works too.

    Brian