On 04/30/06 at 12:19am +0300, marcelo bagnulo braun
<marcelo@it.uc3m.es> wrote:
El 29/04/2006, a las 23:21, Marshall Eubanks escribió:
i am sorry but i am not sure i understand... are you considering
the
case where the proxy is located in the soho or in the content
server
network?
Neither - where the proxy is located on my network.
I am sorry but i am completely lost here...
and who's network is this? i mean, is this a provider's network?, i
guess so, but who's provider? the dentist's? and what is the point of
locating a shim proxy in a provider, when you are looking for is
resiliency against provider failures...
I can't speak for Marshall, but perhaps he's thinking what I'm
thinking...
We (Internap) are a massively multihomed ISP/NSP, with each of our
sites
having its own ASN, and having transit connections to roughly 5-8
tier 1
NSPs. We sell higher performance connectivity than our upstreams can,
which we can deliver because we optimize our BGP routing to choose the
best path for every route in our table.
So a logical business for us (or one of our customers), if shim6
becomes
popular with SOHO's but not with content providers, would be to
provide a
third-party shim6 proxy service. Our proxy would have one IPv6
address
for each of our upstreams, as well as an address out of our own
block that
is advertised via BGP to all of our upstreams. We could then
redirect the
shim6 traffic to our proxy (via routing and possibly tunneling
tricks),
and perform shim6 context establishment on behalf of a non-shim6-
capable
host if the other side tries to set it up. We'd likely leave ULID-
ULID
traffic alone, but if a failure is detected REAP would trigger our
shim6
proxy into action, and it could allow the shim6-capable host to
rehome to
a different locator pair. The traffic from the shim6 proxy to the
non-shim6-capable host would still rely on BGP to reroute traffic
around
any failures on that path.
-Scott