[ppml] a modified proposal 2005-8

[Owen DeLong]

>> The timeliness of global updates only needs to be better than DNS if
>> the churn rate is higher.  If instead of changing the addresses,
>> we change indirect the addresses to one or more routing locators
>> through the same database, then, the routing locator updates don't
>> actually need to be all that timely since they will not change
>> often (where often is defined as a given record changing more
>> than once every 5 minutes or so).
> 
> No matter how you do it some part of a distributed database will need
> timely updates. Shell games claiming to make the problem go away by
> moving them somewhere else don't actually solve the problem. This is why
> the double nat locator replacement approaches fail. You can always know
> enough locally to do the front end part, but getting that propagated to
> the system that will have to translate back (and even knowing where that
> is) will be a non-trivial problem. 
> 
Which is why I propose not doing the back end part.

My proposal is that the first DFZ capable router in the path traversed
by the packet would perform a lookup to map IP->ASN(s).  Then, from
that lookup, it would insert the ASN into a type 53 extension header.
Subsequent DFZ routers would forward towards the tagged ASN ignoring
the unaltered prefix address in the destination field until the packet
arrived at the tagged ASN.  It would then be prefix routed based on
the original destination prefix still contained in the packet.

Thus, the only distributed updates required are:

	1.	IP->ASN mappings (which only change when a prefix moves
		from one ASN to another, not a particularly rapid process)

	2.	AS Path data (which is a subset of what BGP currently
		distributes).


> And the reason that all records are not set with short ttl's is that the
> resulting query rate would cause the global system to roll over. The trick
> is knowing at least the current ttl's setting in advance that you will
> need to move so you can set it short soon enough to affect the move in a
> timely manner; then setting it back to a long value after the move to
> reduce query rates. 'Just set the ttl' is an easy generalization to make
> when it has sufficient advanced notice. It also requires someone with the
> technical understanding to know what to change and when. 
> 
As a general rule, people don't move their prefix from one ASN to another
without some advanced notice.  Very few DNS records have more than an 86400
TTL.  If you have more than a day's advanced notice, you're good to go.
A lot of people today use 900 seconds on records they expect to update
somewhat regularly (and the resulting query rat hasn't killed the system
yet).  Is 15 minutes really that long to wait if you failed to plan your
network move?

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060319/4a06235e/attachment.sig>