North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: shim6 @ NANOG (forwarded note from John Payne)

  • From: Iljitsch van Beijnum
  • Date: Tue Feb 28 14:23:18 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 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.