On 28-feb-2006, at 17:09, Kevin Day wrote:
Some problems/issues that are solved by current IPv4 TE practices
that we are currently using, that we can't do easily in Shim6:
Well, you can't do anything with shim6 because it doesn't exist yet.
That's the good part: if you speak up now, you can get capabilities
added before the spec is finished.
1) Prepending/tagging routes to influence the amount of inbound we
receive from certain providers
Should be doable with a DNS SRV record like mechanism. Don't worry
too much about this one.
2) Announcing more specifics to some peers/transit to influence
which POP certain traffic is received
Actually you could still do that with shim6: whatever happens between
you and your ISP is your business and doesn't inflate the global
routing table. In practice, you'd probably have different /48 blocks
for different POPs to begin with so for stuff where you can
differentiate on destination address, you can very easily get the
traffic to the place where you want it to be.
3) Announcing less specifics (total aggregate announcement) to
"backup" transit provider/connections that we don't want to receive
traffic on unless something is really really wrong
This is something that is incompatible with shim6. So if we want to
retain this functionality, we have to go back to what you're really
trying to do and then come up with a new, shim6-compatible way of
doing it.
4) Being able to do 1-3 in realtime, in one place, without waiting
for DNS caching or connections to expire
How fast is real time?
And are we just talking about changing preferences here, or about
what happens when there are outages?
5) Being able to make routing/policy changes without having to rely
on the owners/administrators of the machines/sites/domains
themselves to do the right thing. (i.e. untrusted/not-maintained-by-
us systems/networks on our network)
If you're a multihomed hosting company you would want to do TE for
your entire POP, but you wouldn't necessarily be able to change
information in the DNS for all the hosts/services that your customers
run. Is that what you mean?
6) Anycast?
I don't think shim6 applies to interdomain anycast. (Which is a hack
anyway.)
7) During what will be a very lengthy dual-stack transitional
period, having to do TE in two entirely different ways. BGP
+Prepending+Selective-announcements along side Shim6 doesn't really
sound like fun to me. We can't treat bits as bits, we have to
consider if they're IPv4 bits or IPv6 bits, and engineer them
differently, even though they're sharing the same lines and are
probably going to have a 1:1 addressing relationship between IPv4
and IPv6 services.
:-)
This is a result of the transition to IPv6, regardless of shim6.
On top of those, even if shim6 accomplishes the failover and
reliability goals, I can't see how shim6 is going to make path
decisions as optimal as IPv4/BGP/etc.
Really??? The way I see it, BGP decisions today are mediocre at best.
If anything, I would expect things to get better with shim6.
My last IPv6 experiment proved that if we're going to provide IPv6,
it has to be as fast to the end user as IPv4 is, or users will
switch off their IPv6 stack entirely. If an end user is running a
dual stack system, sees slow performance a non-optimal path being
chosen via shim6, they'll turn IPv6 off so they can reach the IPv4
version of the site. Anything we do has to ensure that IPv6 has AT
LEAST the same visible performance to the end user, or they're not
going to be willing switchers.
Tell it to the people who still do IPv6 routing the way they did in
1999... It's not much fun to go from one part of Europe to another
through Japan. Fortunately, this is getting better all the time, but
we're not there yet. But also orthogonal to IPv6.
