Google preparing for full roll-out?

Google shuffles around some more DNS records et voilá:

• mail.google.com now resolves to a Google-owned IP (one of the cpt01s01 series)
• mt.google.com now resolves to a Google-owned IP (as above, so below)

Was the hosting of the Google Maps tiles on the [presumed] GGC caching box just a fig-leaf, a ploy for respectability? Since only YouTube access still seems to be directed towards those caching boxen, perhaps that traffic was a quite-substantial chunk of the original Google traffic to TENET's network, the rest of which is now easily handled by the local peering arrangement.

It might allow easier filtering or shaping for the IT/ICTS departments so inclined, but why else keep the YouTube traffic on those boxes? Google's purported 'boxenertia'?

However, seeing that GMail is now locally hosted, that means the major services are being served from local machines. Perhaps this means Google is getting ready for a full-bore load test, in preparation for a proper roll-out?

Google tuning

Even though Google's new Cape Town nodes are in limited production / test mode, users have been connecting to both the local data-centre, as well as to overseas datacentres [e.g. London?].

Presumably Google is still tuning the DNS based on usage while simultaneously expanding the datacentre capacity.

Interestingly it is only mail.google.com that returns a non-local host. So apparently mail is not amenable to normal caching modes or it would have been done through either the [presumed] GGCs or even transparently cached within the Cape Town datacentre.

Let's hope that Google get some cheap capacity on SEACOM even though is has higher latency than SAT-3 (~215 ms vs ~150 ms). Since most of the front-end logic (e.g. client javascript) would be served by local machines, interactivity should not be compromised too much.

ASN fail by default

Ahhh TENET, you continue to be the source of interesting and alternately amusing/depressing news:
[from the REN-news mailing list]

As of the 1st of January, all the Region Internet Registries (RIR's),
that being, AfriNIC, APNIC, LACNIC, RIPE and ARIN have adopted a policy which allocates 32bit ASN's by default
...
[A]lmost no networking equipment out there
currently supports these.
...
This means that should you get a 32bit ASN instead of a 16bit ASN, it
will not be useable to peer with or announce to the TENET network or
most other networks at this point.

I suppose this is a bit like the USG jump-starting DNSSEC by requiring it be present for the .gov TLD. But only a little bit, because in this case the pressure on the vendors is going to be coming from annoyed customers.

And since there's no backwards-compatibility built-in (no fall-back number), Metcalfe's Law works against one here: everyone you need to peer with also needs updated equipment and/or software.

Gro'in' pains

Enough 80's references, let's skip to the meat of this post (so to speak). This is from a recent traceroute; DataHop might want to rename one of their nodes to accomodate some expansion in their traffic:

11 196.32.209.25 (196.32.209.25) 165.620 ms 160.809 ms
12 ge2-20-0-cr0.tch.uk.as6908.net (78.41.155.161) 236.578 ms 198.183 ms
13 te-4-2.r00.londen05.uk.bb.gin.ntt.net (83.231.146.69) 151.840 ms 153.098 ms