Hi,
I'm guessing from the quietness of the list that many people are on
vacation, but for now, here is the proposed action on this point:
- a change to the Flood message format that adds a TTL field
and a locator field (in the same format as in a Discovery Response).
Both of them can be null (which means infinity for the TTL).
- add a TTL field to the Discovery Response too. This makes the Flood
and Discovery Response message formats essentially identical.
We'll also add a recommendation that flooded objectives should be
repeated at a suitable frequency. Otherwise, there is a problem
for new or sleeping nodes.
Regards
Brian
On 12/08/2016 09:15, Brian E Carpenter wrote:
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
