Forgot to subscribe to nanog-post first time round...
Long story short, seperating endpoint/locator does nothing to allow
multiple paths to a single IP6 address/prefix to scale.
I may be wrong - I haven't been following shim6 for long, but to me it
does appear to scale because it is moving the host identity problem from
being an IP address that exists in a single long prefix in the core
routing table to being an identifier (128 bit number) which maps to a
number of existing IP addresses which each already live in much shorter
prefixes in the core routing tables. i.e. move the problem from the
core to the edge nodes. Those edge node only need to locator lookup
tables for the hosts they are talking to - not all that they may talk
to.
e.g.
Say there is a host a::1 and my server has 3 IP addresses b::1, c::1 and
d::1, via service providers B, C and D.
As it stands, obviously a::1 can talk directly to the server using any
of the addresses. Now, say I want to multi-home. Obviously in the
past, I would have gotten my own prefix, say e:: and ASN and announced
it. But now with shim6, I could use e::1 as the identifier for my host
and use b::1, c::1 and d::1 as the locators.
So now someone requests a AAAA for my host and gets back e::1.
Now when a::1 tries to connect to e::1, the shim does a lookup and sees
three possible locators - b::1, c::1 and d::1. It selects one of them
and packets are then routed between a::1 and one of b::1, c::1 and d::1
in the same way that they would today.
How are there traffic engineering problems when at the end of the day
the packets will still be routed in the same way? Or am I missing some
crucial point?
Regards,
John