[Anima-signaling] Session IDs in relayed messages (and the Initiator field)

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

Bing,

> 2. Section 3.3.5.1 Flooding
>> If it receives a multicast Flood message on a given interface, it MUST relay it by re-issuing a Flood message on its other interfaces. The relayed message MAY have a different Session ID.
> [Bing] Is there any concern that different Session IDs for the same flood message?
> My rough idea is that the same Session ID might be beneficial to identify the flooded message. E.g., the interface could easily examine whether the message had been relayed once.

That was what I thought until I started writing the code. It gets very complicated
because of the "birthday paradox" risk of duplicate Session IDs. You have to track
the pair (Session ID, initiator address). That's why I proposed adding an 'initiator'
to several messages (see the discussion with Carsten attached below). The issue is
just the same for flood and discovery.

Relying on the loop count to terminate multicast loops is much simpler.

There are only two ways to create a loop: a bad physical topology, which will create
problems for everybody, not just GRASP, or a faulty GRASP implementation that relays
multicasts back to the same interface, which will be detected during debugging.
So I think the loop count is enough protection.

If we accept that, then using a new Session ID each time a multicast is relayed
to a new link is fine. We do lose the knowledge of which GRASP node originally
generated the Discover or Flood.

What do you think? There would be a few more changes to the text for this.
I have two versions of the Python code already, with or without the 'initiator'
field, and they both seem to work with identical results.

Regards
   Brian

On 11/01/2016 08:38, Brian E Carpenter wrote:
> On 11/01/2016 07:52, Brian E Carpenter wrote:
>> Hi Carsten,
>> On 11/01/2016 02:38, Carsten Bormann wrote:
> ...
>>> More odd to me is that the session-id only makes sense in conjunction
>>> with the initiator, but the latter is not always given.  I can't quite
>>> make rhyme and reason out of when it's there and when not.  Maybe that
>>> should be explained in the text (beyond what's in 3.6), including how
>>> the initiator is implied when not present in the message (source IP
>>> address of UDP packet?).
>>
>> The issue only arises at all because of the need to relay discovery
>> and flood packets from one interface to another. In all other cases
>> the source address of the packet is fine for disambiguating sessions.
>> And in my implementation, the issue doesn't even arise for relayed
>> discovery messages, because it proved easier to launch a new discovery
>> session than to propagate the old one.
>>
>> You know, I'm going to look at my code again. If I can do the same trick
>> for flood messages when they are relayed, we just wouldn't need the
>> stupid initiator field at all.
> 
> I had to add three lines of code to the relay function to do this.
> So I now propose to remove the 'initiator' field from the messages where
> I added it (and add the necessary clarifications about using the source
> IP address). That will be a straightforward change to the -02D draft
> that I sent yesterday, so co-authors, please let me know what you think
> ASAP.
> 
> Thanks Carsten, this helped a lot.
> 
>     Brian
>