shim6 @ NANOG (forwarded note from John Payne)
Iljitsch van Beijnum
iljitsch at muada.com
Tue Feb 28 19:22:04 UTC 2006
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
> 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
> 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.
More information about the NANOG