...
Also, note that a beacon every day means a timeout of 3 days.
Previous suggestions were a timeout of ~24 hours and a beacon of ~8
hours.
I think your characterization is accurate, i.e., a TTL of 24 hours which
implies a more frequent beacon rate, to avoid a signed route from expiring.
An alternative to beaconing is a push model instead of pull. That
is, every router registers it's interest with the repository instead
of querying it periodically. Then the repository would tell all
registered parties when a change occurred rather than waiting for
them to ask.
Every AS that does not rely on default routes is potentially "interested" in
the freshness of every origin's route announcement. So I don't see how
a registration approach to trigger pushes will help. Also, a motivation for
pushing the route freshness info via updates is because this reduces
the need for frequent access to the repository system. The downside
is that it creates
the need to "refresh" a route that might otherwise not need to be announced.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
