[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)]
On 2007-06-23 14:04, Robin Whittle wrote:
I wasn't suggesting any change to SHIM6's development. What I
wrote:
SHIM6 is clearly not the portability and multihoming system most
end-users want, so on its own, it has not been enough to make people
want to adopt IPv6 without PI address space.
seems to be factual.
No. If shim6 was shipping code in the popular operating systems, we could
start the clock on that evaluation. Since it isn't, it's way too soon
to say anything.
Noel wrote:
A architectural-level discussion of why people are unhappy
with SHIM6, and how that relates to those inescapable
technical drivers, might not be out of place here...
I agree.
First of all, please identify those people. The ones who were
identified in last year's round of meetings with IAB members have been
heard from, and their main issue - lack of ISP control over multihoming
policy - has certainly been heard. As far as I understand the history
of these discussions, we're here to look for another solution that
has that property, which would certainly move the control point for
locator selection out from the host towards the border router
or beyond.
I think a global system for LISP, Ivip or similar will be built.
I think this system will provide good portability
I'm not sure exactly what you mean by portability.
and hopefully
TE for ordinary hosts - IPv4 or IPv6 -
Hosts aren't interested in TE. That is an enterprise
network operator, or ISP interest.
without additions to the
protocol stack or changes to operating systems.
You should know that one of the reasons we took a host based
approach in developing shim6 was because we saw no sign of
a proposal to solve the problem in the routing system. So, now
we have a near-ready host based solution. Why can't we just
let it become ready and see if it works? Why let shim6 be a
distraction here?
I think this
has to happen soon for IPv4, because the BGP system can't be
expected to keep up with the growth in the number of advertised
prefixes. We have to find a way to provide portability,
multihoming, TE and ideally great mobility for millions of
end-users, without altering hosts.
SHIM6 would still work with any such LISP or Ivip system for
IPv6 - so it is "orthogonal" to any such system. However the
things which SHIM6 would provide would already be largely or
entirely available via the LISP/Ivip system.
So what? The approaches are orthogonal, as you say.
I understand that SHIM6 is basically a host-oriented system,
operating on a single IP address at a time,
It operates on a locator set.
with the control
necessarily being exercised within the multihomed host itself.
Final choice is made in the shim. There's no reason the
policy that determines the choice shouldn't be
distributed site-wide - that's why RFC 3484 is relevant.
And there is a draft on a shim6 proxy, but that raises
some standard stateful-proxy issues.
I may be wrong - it is complex and I haven't properly read
draft-ietf-shim6-proto.
LISP/Ivip, as I envisage it working, can handle individual IP
addresses or arbitrary sets of addresses with equal ease,
I think NERD only scales if it handles prefixes, not /128s
or /32s.
and
does not require any new software or for the host(s) whose
addresses are being managed to be in any way aware of it.
Nonetheless, a single host could manage its own LISP/Ivip
mapping, or some centralised system could perform this task for
it, for instance to choose the best ETR in a multihoming setting
when one link fails.
Yes, that might be a way for users to take control back from ISPs,
although I think shim6 will prove an easier way to do that.
Brian
_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram