[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] On the Transitionability of LISP

On 2007-08-02 09:24, Christian Vogt wrote:

Folks,

I brought this up at the microphone during the RRG meeting in Chicago,
but would like to elaborate with more details here on the mailing list.

There is a transition problem with any ID/locator split mechanism that
requires mapping functions both locally at an edge network, and remotely
at any correspondent edge network that the former edge network may
exchange traffic with.  One such mechanism is LISP, where the local and
remote mapping functions each take the form of an ITR/ETR pair.


There are two things in the shim6 design that avoid this problem
(as part of shim6's "first, do no harm" principle):

1. The ID in shim6 is also a globally valid locator.

2. If the other end doesn't respond to shim6 messages, shim6 is a
no-op.

In any solution, if the other end doesn't respond in a way that
makes it clear that it supports the solution, then we can assume
that it still has valid routeable addresses that can be used. In
that case, the host at this end would need a legacy routeable address
to obtain connectivity. In other words, during the coexistence
era, hosts would need one ID-style address and one PA/PI style address
per address family.

I think this is more deployable than coordinating an anycast
solution.

    Brian



The requirement for support on both sides implies that an "upgraded"
edge network using mapped IDs will no longer be reachable from "legacy"
edge networks that do not yet support the mapping.  This is a
disincentive for edge networks to adopt the ID/locator split mechanism
during an early transition stage.

The only way I see to get around this disincentive is the approach of
Ivip:  Decouple the remote mapping function from potential correspondent
edge networks, move it further into transit space, and use anycast IDs
to reach it.

(The reason one needs anycast IDs is to let multiple alternative
providers perform the same remote mapping for an edge network.  Unicast
IDs would bind the remote mapping to a single provider.  This would
create a dependency of the edge network on that provider, which is
exactly what we want to avoid with multi-homing.)

A side effect of anycast IDs is a change in the Internet business model.
 Edge networks today only need business relationships with providers
they directly connect to.  A transition towards mapped anycast IDs would
require an edge network to additionally subscribe to the remote-mapping
service of multiple providers further inside transit space.

As many as possible remote-mapping subscriptions would be needed per
edge network to limit the increase in packet propagation delays, which
the new, triangular routes via a remote-mapping provider would entail.

Coordination would be required between remote-mapping providers.  The
providers would need to jointly administer a large, aggregatable block
of anycast IDs, and consistently map slices of this to the locators of
subscribing edge networks.

- Christian



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg