Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]

[Igor Gashinsky <igor@gashinsky.net>]

On Sun, 16 Apr 2006, marcelo bagnulo braun wrote:

:: Hi Patrick,
:: 
:: El 16/04/2006, a las 20:20, Patrick W. Gilmore escribió:
:: 
:: > It is not just backbones.  Shim6 is not commercially viable.  Period.
:: 
:: Would you care to comment why do you think this?
:: 
:: I mean what are the commercial requirements that shim6 fails to fulfill?
:: Perhaps there is away to make it more similar to what you would expect...
:: 
:: Is this for a certain type of sites, or is it in general for any type of
:: multihomed site?

Marcelo,

	It's the same basic problem that I wrote about earlier. For Shim6 
to be viable, it must be deployed on both the Client and the Server side. 
Given the overhead that this solution would place on the Server side 
to get the job done "right"[1], I do not believe that the Content 
providers would chose to support it (speaking as a network architect for a 
content provider, but again, not officially representing my 
employers views). 

Over the past few months of watching this list, what I've basicly 
witnessed is that people either don't believe that those are 
relevant/realistic requirements, or believe that the current solution's 
benefits outweigh the drawbacks of lack of those features. I really wish 
that people would listen to what Patrick and I are saying, and that as 
engineers for 2 of the worlds largest content networks, we will *not* 
accept a solution that does not meet those requirements, and if you would 
talk to our peers (as we have), neither will they. At this point, without 
content, the solution will be simply useless, since it will not be 
deployed widely enough to matter; sorry, but that's the truth. 

I understand that it's not finished, but I have not seen *1* step towards 
addressing those problems adequately. While I respect the premise that 
engineering is all about making tradeoffs, I just can not accept the 
premise that "the solution" must either be a fully featured system (as we 
have right now in IPv4) or a scalabale routing architecure. That's not a 
"solution", as it does not address the problem it is trying to resolve. 
As Patrick is saying, you can not simply say "we have a solution, it 
breaks lots of stuff you are used to doing, it is going to cause you 
major operational harm, but it's the only thing we can think of right 
now", and expect businesses and bend over backwards to deploy it -- those 
businesses will just say "go back to the drawing boards", and that's 
exactly the message we are trying to pass on.

As far as what Jason/Joe are saying, I really don't believe that the world 
is coming to an end if we continue on our current trend (and Jason, my 
question, again, is "would you really feel the way you do now if you 
didn't miss your last upgrade cycle?"), and neither do our vendors. People 
fully expect for the *current* memory architecture to scale *at least* 
6-fold (and nobody expects for the FIB to expand that much over the next 
5-10 years with the ipv6 adoption, the most aggressive numbers I have 
seen is a 3-4x increase), so I think we have plenty of time to come up 
with a solution which meets all the requirements *and* delivers a more 
scalable routing architecture. At least then, we'll have a real answer, 
and can honestly say that we've "solved the v6 multihoming issues".

Thanks,
-igor (speaking strictly for myself, and not my employer)

[1] Those requirements, which shim6 currently fails to meet, again, are:
1) equal or better TE capabilities to PI multihoming in IPv4
	a) those capabilities controled site wide, not host-wide
	b) those capabilities covering all deployment scenarious that IPv4 
	   currently covers and people use heavily (ie inbound/outbound 
    	   TE, transit TE, partial routes TE, peering TE, etc)
2) equal or better convergence around failures as IPv4 ie (1st packet 
	shim)
3) do all that without an undue burden on the server/SLB/proxy device