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: Kevin Day
  • Date: Tue Feb 28 11:08:13 2006 
On Feb 28, 2006, at 6:31 AM, Iljitsch van Beijnum wrote:

[Crossposted to shim6 and NANOG lists, please don't make me regret this... Replies are probably best sent to just one list for people who don't subscribe to both.]

On 27-feb-2006, at 22:13, Jason Schiller ([email protected]) wrote:

Is it the consensus of the shim6 working group that the full suite of TE
capabilities should not be a requirement? Or is this just the opinion of
a few vocal people?
I don't think I'm going out on a limb when I say that there is consensus that we need good enough traffic engineering from the start. (Where "start" means deployment, not necessarily the publication of the first RFC.)

I think basic balancing of both incoming and outgoing traffic over the available links is both assumed to be part of what we need to have and implementable without too much trouble.


Some problems/issues that are solved by current IPv4 TE practices that we are currently using, that we can't do easily in Shim6:

1) Prepending/tagging routes to influence the amount of inbound we receive from certain providers

2) Announcing more specifics to some peers/transit to influence which POP certain traffic is received

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

4) Being able to do 1-3 in realtime, in one place, without waiting for DNS caching or connections to expire

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)

6) Anycast?

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.


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. 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.

I'm not saying that shim6 is going to CAUSE routing problems, but a lot of thought is being given to localprefs, MEDs, prepending, and bunch of other strategies to select the best path for a given destination. NSPs have designed their routing policies (hopefully) to take the best path whenever possible, and BGP allows for those decisions to change in relatime. Shim6 is capable of picking a valid route, but can't see enough into the network to select "best". It works if you want to maintain reliability, but not if you're multihoming to increase performance, not just stability.

Shim6 is great for a lot of people. I know that not everyone wants to run BGP just to handle multiple connections. But, Shim6 isn't a replacement for what a lot of us are doing now.