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

[Toerless Eckert <[e-mail]>]

Inline.

On Mon, Aug 01, 2016 at 08:47:22AM +1200, Brian E Carpenter wrote:
> Hi,
> 
> Prior to raising this on the WG list, I'd like feedback from the design team.
> 
> Following side discussion with the bootstrap and ACP teams in Berlin, there
> is a new issue about flooded objectives (not really about the Flood message
> itself). It has two aspects:
> 
> 51.1 Should flooded objectives have a time-to-live before they are deleted from
> the flood cache? I think the answer is no, because in any case the source can repeat
> the Flood message if the value changes. If anybody sees a use case for a TTL,
> please explain it.

We discussed in Berlin methods to discover sources that went away:

a) IMHO, we do not want to send rapid updates from sources to discover quickly when
   they die because of the absence of those announcements. (aka: no fast aliveness).
b) IMHO we do not want to work out the details of the GRASP infra quickly detecting
   when a sources goes away and flood that information (no IGP like fast source revocation).
c) I suggestested that GRASP clients could help:
   - GRASP thinks source is alive (long or no TTL)
   - GRASP API client tries to connect to objective, and fails
   - GRASP API client tells GRASP "objective seems dead".
   - GRASP removes objective source from cache
   - When GRASP receives another flood message from objective source,
     it repopulates cache and tells client.

With c) in mind, we might not need a TTL, but I am not aware of existing service
announcement mechanisms that tried to rely on this "c)" approach, so i am a bit
weary to solely rely on it:

When there is a network disconnect between objective and client, the client would not
be able to reach the objective and the objective would be declared dead. Aka: If we
do "c)", we do need to periodically flood from the objective source the announcement
to recover from this situation. The periodicity should be determined by the source
itself. But it would be good if the source also announced this periodicity.

Aka: I would suggest that intead of TTL, the source could simply announce the periodicity
of it's announcements (in seconds). Default 30 seconds.

If a client does not perform "c)", then it can use the periodicity value to
calculate when it can declare the source dead - eg: after three periods non-receipt
of a message.

There is also a fundamental limitation with "c)", and that is when the announcer
is not tightly coupled with GRASP:
   - GRASP could announce the objective, but the process providing the objective
     could be running on a different system and could have died. Or maybe this is
     even possible on the same system.
   - Client connecting to the objective  would declare it dead to GRASP, but
     GRASP would continue to see announcement from the source.

Ideally, we would not have this case, aka: GRASP API should always know when
the actual source of the objective is really alive. But i am not sure if it's possible
to always guarantee this. So it would be good to have in the flooded objective
some indiciation that the GRASP announcement is not coupled to the objective aliveness
itself.

I am extrapolating this case from what we do with mDNS: Most services today do
not couple to mDNS via API. Instead when we use something like Avahi, then there
are Avahi config-files that describe the services running on the same system (or
on another system). Which of course does not guarantee that each of those services
is actually working fine. So i't seasy to announce services when they do have
problems (eg: can't start, fail, ...).

Aka: objective parameter "GraspObjectiveCoupled" (or come up with a better name).
If true, it means that the GraspSource and Objective Owner feel that it's safe
to do c) on the client side to discover death of the service, and false means it is not.


> 51.2 We do have a potential use case where more than one source floods the same
> objective, and the recipient ASAs need to distinguish the results. That use case
> is when there are multiple bootstrap proxies advertising on the same LAN, and the
> joining nodes (pledges) can choose which one to try. I'm sure there will be others.

The most important one being multiple registrars announcing the registrar service,
and the bootstrap proxies want to discover them, and then choose the best one based
on network distance (aka: remaining loop count).

> My proposal is to specify that a node receiving a Flood message will cache
> the received objective plus its source locator (which is already in the message
> for other reasons). We'll also have to upgrade the API so that the recipient
> ASA can get multiple flooded answers.

Yes.

Thanks!
    Toerless
> 
> Comments?
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima-signaling mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-signaling

-- 
---
Toerless Eckert, [e-mail]