Re: [Anima-signaling] GRASP issue 51: Flooded objectives

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

Hi Toerless,

Catching up on your issues. I think most of them are covered by
adding the TTL and locator info to Flood. A couple of points remain:

> When we
> use link-local-multicast, there is no guarantee that it will be received
> by all nodes. I would actually prefer to use the ACP TCP connections also
> for the flood-sync inside the ACP to make them reliable. One for each ACP
> neighboring autonomic node. No UDP multicast.

Actually this gets back to something I was beating Michael (Behringer) up
about. I would love it if the ACP could do this. From a coding point of
view it would be nicest if the ACP could catch packets sent to a
LL multicast socket (by behaving like a virtual link) but that's a detail.
It would be OK too if the ACP simply provides functions to call instead
of sendto(msg,0,(ALL_GRASP_NEIGHBOR_6, GRASP_LISTEN_PORT)) and the
matching recvfrom().
...
> What happens with a node newly rebooting. How does it get those existing
> flood objectives ? 
...
> Aka: periodic, low-frequency broadcast is a proven stable solution. Its
> not the nicest. It may not be the only one we want in GRASP, but i'd
> feel a lot safer if we could make that option work.

Yes, and it's easy - because the sending ASA can just do it, at a
frequency that suits the particular objective. Also, a node that
doesn't want to wait for the next flood can do a standard GRASP
unicast synchronize action.

> But we will still be left with
> the issue of withdrawal...

Like DNS TTLs. If you know in advance that something should be
withdrawn soon, you refresh it with a short TTL. But if there's
a fault:

> Example: Registrar announces lifetime of LONG. WHole network learns it
> AN3 goes down, AN4, AN5 stay up. Registrar is replaced by other registrar.
> AN3 comes up. AN4, AN5 will still have ld registrar flood sync cache
> entry - which will not time out for a LONG time.

When a client (a proxy in this case) tries to connect to the old registrar,
there will be a hard socket failure. So the client needs to look for
another registrar by repeating discovery or waiting for a new flood.

But looking at sone of the pseudocode you sent earlier in the thread,
I added a new call to my Python API:
 expire_flood()
# Mark a flooded objective as expired
#
# This is a call that can only be used after a preceding
# call to get_flood() by an ASA that is capable of deciding
# that the flooded value is stale or invalid. To be used
# with care.

It needs 8 lines of python :-). It's only local; to expire
something globally would need a new GRASP message type, but
wouldn't actually be hard to do if we wanted.

Regards
   Brian