shim6 @ NANOG (forwarded note from John Payne)

Tue Feb 28 16:09:47 UTC 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 (schiller at uu.net) 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.