Hi Lotte,
In which version did we remove the timed state? The timed flag has now also
been removed, so the way we know if the route is timed is that expiration
time is not MAX_TIME (it will be earlier).
Regards,
Vicky.
On Mon, Jun 1, 2015 at 3:38 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, Hi Charlie,
ooh, that makes a lot of sense. Thanks for the clarification. But I fear I
have another question in that direction:
I'm still in the process of catching up with all of our changes with my
implementation (yup, running awfully late, I'm doing as much as I can), and
when I wanted to get rid of the Timed state, it occurred to me that, while
our change logs say that we got rid of the Timed state, the timed flag they
say it has been replaced with.. I just can't seem to find it. Am I
overlooking something or did the “short description of timed route” (as
it says in the changelogs) in the Route Table section get lost somehow?
Regards,
Lotte
Am 16.05.2015 um 21:25 schrieb Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx>:
Hello folks,
I agree with Vicky's interpretation. Essentially, no route can *actually*
have a timeout at MAX_TIME, and so MAX_TIME can be re-used as an escape
value to simplify other processing.
Regards,
Charlie P.
On 5/16/2015 11:09 AM, Victoria Mercieca wrote:
Hi Lotte,
I interpreted MAX_TIME as a way of saying "forever" or "no definite
limit". It's the maximum possible value of time, so you couldn't calculate
current time + MAX_TIME. If ExpirationTime is set to MAX_TIME there's no
real time at which the route should expire. The time the route becomes
invalid should be based on if it's in use, so we still have the behavior
that it becomes invalid after active interval and idle time. The route is
useful as long as it's in use, which can be beyond the seqnum lifetime.
I hope that helps. This was only a quick reply tapped in from my phone!
Kind regards,
Vicky.
On 16 May 2015 18:15, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx>
wrote:
Hi all,
again, I guess I'm pretty late to the party, but when I went to update my
code to include MAX_TIME today, I realized it confuses me a bit. Section
6.5.2. says:
o Route.ExpirationTime := CurrentTime + AdvRte.ValidityTime if a
validity time exists, otherwise MAX_TIME
It seems that all Timeouts except for MAX_TIME seem to be CurrentTime
plus some kind of offset, shouldn't it also be CurrentTime+MAX_TIME?
Then, I went on to see what happened to the old approach (i.e. the
default validitytime is ACTIVE_INTERVAL + MAX_IDLETIME) and found this in
the pseudocode:
if ((CurrentTime - route.LastUsed > ACTIVE_INTERVAL + MAX_IDLETIME)
AND (route.State != Unconfirmed)
AND (route.ExpirationTime == MAX_TIME)) //not a timed route
route.State := Invalid;
There seems to be some distinction between MAX_TIME and the old
ACTIVE_INTERVAL + MAX_IDLETIME, but I can't find an explanation in the
draft... Am I missing something here or is this legacy pseudocode?
Additionally, the fact that there is no value for MAX_TIME yet is a bit
hard to implement. Intuitively, I'd just set MAX_TIME to ACTIVE_INTERVAL +
MAX_IDLETIME, since it doesn't really make sense to me that a route times
out long after it has passed the time frames in which it can be of any use.
Again, am I missing a point here or would this make sense?
regards,
Lotte
