On Tue, 13 Oct 2009 00:46:00 EDT, Kevin Loch said: > Adrian Chadd wrote: > > On Tue, Oct 13, 2009, valdis.kletni...@vt.edu wrote: > > > >> You get some substantial wins for the non-TE case by being able to fix > >> the legacy cruft. For instance, AS1312 advertises 4 prefixes: > >> 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 > >> but on the IPv6 side we've just got 2001:468:c80::/48. > >> > >> And we're currently advertising *more* address space in one /48 than we > >> are in the 4 IPv4 prefixes - we have a large chunk of wireless network that > >> is currently NAT'ed into the 172.31 space because we simply ran out of room > >> in our 2 /16s - but we give those users globally routed IPv6 addresses. > > > > > > I suggest you're not yet doing enough IPv6 traffic to have to care > > about IPv6 TE. > > I think he was pointing out that extra routes due to "slow start" > policies should not be a factor in v6. My guess is that is about > half of the "extra" routes announced today, the other half being > TE routes.
Exactly. We have 4 prefixes only because we got slow-started and similar hysterical raisins, we don't use those for TE at all. If we wanted to do any globally visible TE that actually made a difference, we'd have to announce a more-specific out of one of the /16s anyhow, since that's where all our traffic generators/sinks are (and probably a matching more-specific out of our v6 /48). So we're always going to have 4+N on the IPv4 and 1+N on the IPv6 side. (And if we'd gotten more address space for that wireless net, we'd be at 5+N rather than 4+N).
pgpHVfLZqXviF.pgp
Description: PGP signature