Hi WG,
This rather long message expands on GRASP issue 51, which is summarised as:
51. Should flooded objectives have a time-to-live before they are
deleted from the flood cache? And should they be tagged in the
cache with their source locator?
This has led to a complicated discussion in the signaling design time (mainly
between me and Toerless) and we would like feedback from the WG before taking
any firm decisions.
Breaking it down into separate issues:
51.1 Should flooded objectives have a time-to-live before they are deleted from
the flood cache?
Cutting a complex discussion short, it seems that we will surely have use cases
where a time-to-live is needed. It might be infinity, of course, but we might
also
want to be sure that a flooded objective vanishes after 30 seconds. To do that,
we
need to add a TTL field.
Q1: Does the WG agree to add a TTL to the Flood message?
51.2 We do have at least one 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 more than one Registrar or Proxy announces its
availability
via a flooded objective, so that joining nodes don't need to send an insecure
Discovery message during bootstrap.) So the flood cache needs to record the
source of the flooded objective.
51.3 That leads to another complication. Suppose that more than one ASA in a
given
node floods the same objective.
Side issue: I (Brian) had been working on the assumption that only one ASA in
a given node can manage a given objective. "Manage" means being willing to act
as
a negotiation responder, a synchronization responder, or as a source of
flooding.
But in fact, although there might be a reason for that limitation in a
particular
use case, GRASP as a protocol could perfectly well handle several ASAs managing
the same objective. [My prototype implementation cannot really do so, but that's
an implementation choice.]
Return from side issue: If more than one ASA in the same node floods the same
objective, recording the source (as mentioned under 51.2) is not enough. We
would
need to separate multiple instances from the same source node. There is a use
case for this too: if we want to make a soft changeover from version N to
version N+1
of a given ASA, where version N is not switched off until all current sessions
end, but all new sessions will involve version N+1.
This will not cause any protocol changes for GRASP discovery (which already
returns a locator as a 3-tuple {IP address, protocol, port}. Therefore,
it won't cause any changes for synchronization or negotiation, which are
based on discovery results.
But it does mean that to distinguish flooded objectives from each other, we will
need to tag them too with a 3-tuple {IP address, protocol, port}.
Q2: Does the WG agree to add a locator 3-tuple to the Flood message?
When considering these additions to Flood messages, which add a few bytes
of overhead, please consider that for most use cases, the frequency of
flooding would be quite low.
Regards
Brian + signaling design team
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
