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

[Igor Gashinsky <igor@gashinsky.net>]

On Sun, 16 Apr 2006, Scott Leibrand wrote:

:: On 04/16/06 at 10:59pm -0400, Igor Gashinsky <igor@gashinsky.net> wrote:
:: 
:: > [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 controlled site wide, not host-wide
:: > 	b) those capabilities covering all deployment scenarios 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
:: 
:: Igor (and Patrick),
:: 
:: I understand that shim6 doesn't provide a solution for content providers'
:: multihoming needs.  IMO that's one of the reasons we had to go ahead with
:: PI.  However, I wonder how you (and Patrick) would feel about continuing
:: to use PI space in IPv6, and also supporting shim6 to allow the end users
:: you're communicating with to multihome?  In my mind, the balance point
:: would be to configure your servers to not initiate shim6 capability
:: negotiation, to allow negotiation if the client initiates it, and to
:: promptly discard shim6 context after capability negotiation is complete.

Hey Scott,

The problem with this is 2-fold. First, we (still) lack TE. Whereas
right now when a multihomed user initiates a connection to my server, I 
know what the best path is to reach him (taking into account all of his 
providers, BGP gives me plenty of visibility/flexibility), and I can 
perform TE on those packets (what if I peer with one of his providers, and 
not another, or what if one of his providers costs me $X/mbps, and the 
other $10x/mbps). That is something that is completely lacking in 
shim6. The other issue is that I can not simply discard the shim6 context 
once it's initiated (a broken session is not an acceptable scenario for 
me, even for a single HTTP/1.0 GET in ipv4, why would it be acceptable in 
ipv6?), since w/o knowing both ips for the end client, if a client 
re-home occurs, my server won't know that it's the same session, and will 
reset it, so it fails the "equal or better convergence" requirement. 

Also, what makes you think that the lack of TE is acceptable to the end 
user? The way I see it, we are trying to solve 2 very distict problems: 
*client* multihoming (ie end user on dsl, who wants his cable modem to be 
his backup), and *site* multihoming (anything from a small branch office 
with 20-100 users there to a larger one with 500 users, to a server farm, 
all having a real network admins, and even minor bgp-foo) in a single 
solution, but they have 2 very different requirements. One of which, 
currently, has a valid method of multihoming (it's not uncommon for a 
business to get a single PI allocation, and slice it up among branch 
offices, so the sites essentially use PI space, or get PA space form one 
of his providers, and advertise it to both) and the other one (end user) 
does not. Solving the problem for the DSL end-user is potentialy several 
orders of magnitude easier then solving it for the branch site, since the 
end user can't do it currently, therefore has no expectations, and the 
site can, and expects to be able to do things with the same capabilities 
as in v4. 

So, who are we trying to solve the problem for, because if the answer is 
both, shim6 does not work, if the answer is branch office, shim6 still 
does not work, and if the answer is the DSL end-user, how many of them 
really want to multihome, and, like Patrick said, are we trying to solve a 
problem that does not exist? Right now, the scope is "everything", 
so perhaps it's time to break up the problem space, and maybe have 
different solutions for different problems?

Thanks,
-igor