On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote:
> On 11 Mar 2012, at 20:15 , Joel jaeggli wrote:
>
>>> The IETF and IRTF have looked at the routing scalability issue for a
>>> long time. The IETF came up with shim6, which allows multihoming
>>> without BGP. Unfortunately, ARIN started to allow IPv6 PI just in
>>> time so nobody bothered to adopt shim6.
>
>> That's a fairly simplistic version of why shim6 failed. A better reason
>> (appart from the fact the building an upper layer overlay of the whole
>> internet on an ip protocol that's largely unedeployed was hard) is that
>> it leaves the destination unable to perform traffic engineering.
>
> I'm not saying that shim6 would have otherwise ruled the world by now, it was
> always an uphill battle because it requires support on both sides of a
> communication session/association.
>
> But ARIN's action meant it never had a chance. I really don't get why they
> felt the need to start allowing IPv6 PI after a decade, just when the
> multi6/shim6 effort started to get going but before the work was complete
> enough to judge whether it would be good enough.
>
As the person who led the charge in that action, I can probably answer that
question...
First, from my perspective at the time, SHIM6 didn't stand a chance. It was
massively complex, required modifying the stack on every single end system to
yield useful results and mad windows domain administration look simple by
comparison.
As such, I just didn't see any probability of SHIM6 becoming operational
reality. (I think LISP suffers from many, though not all) of the same problems,
frankly.
I remember having this argument with you at the time, so, I'm surprised you
don't remember the other side of the argument from the original discussions.
However, there was also tremendous pressure in the community for "We're not
going to adopt IPv6 when it puts us at a competitive disadvantage by locking us
in to our upstream choices while we have portability with IPv4."
Like it or not, that's a reality and it's a reality that is critically
important to getting IPv6 adopted on a wider scale. Fortunately, it was a
reality we were able to address through policy (though not without significant
opposition from purists like yourself and larger providers that like the idea
of locking in customers).
>> That fundementaly is the business we're in when advertising prefixes to more
>> than one provider, ingress path selection.
>
> That's the business network operators are in. That's not the business end
> users who don't want to depend on a single ISP are in. Remember, shim6 was
> always meant as a solution that addresses the needs of a potential 1 billion
> "basement multihomers" with maybe ADSL + cable. The current 25k or so
> multihomers are irrelevant from the perspective of routing scalability. It's
> the other 999,975,000 that will kill the routing tables if multihoming
> becomes mainstream.
It's not just about depending on a single ISP, it's also about being able to
change your mind about which ISPs you are attached to without having to
undertake a multi-month corporate-wide project in the process.
Let's compare...
BGP multihoming with portable PI prefix:
1. Sign new contract.
2. Make new connection.
3. Bring up new BGP session.
4. Verify routes are working in both directions and seen globally.
5. --
6. --
7. --
8. --
9. Tear down old BGP session.
10. --
11. Terminate old contract.
12. --
PA based prefix:
1. Sign new contract.
2. Make new connection.
3. Get routing working for new prefix over new connection.
4. Add new prefix to all routers, switches, provisioning systems,
databases, etc.
5. Renumber every machine in the company.
6. Renumber all of the VPNs.
7. Deal with all the remote ACL issues.
8. Deal with any other fallout.
9. Turn off old prefix and connection.
10. Deal with the fallout from the things that weren't symptomatic
in steps 4-9.
11. Terminate old contract
12. Remove old prefix from all remaining equipment configurations.
By my count, that's twice as many steps to move a PA end-user organization and
let's face it, steps 5, 6, and 7 (which don't exist in the PI scenario) take
the longest and steps 7, 8, and 10 (again, non-existant in the PI scenario) are
the most painful and potentially the most costly.
No multihomed business in their right mind is going to accept PA space as a
viable way to run their network.
Owen
