Re: [RRG] On the Transitionability of LISP

[Christian Vogt <christian.vogt@nomadiclab.com>]

Mark,

I don't think providers will make their own customers' non-mapped
prefixes sub-optimally reachable in order to speed up LISP deployment,
especially since the providers won't benefit from this themselves.
Furthermore, an ability to prune long prefixes in edge networks would
leave the Internet core with large, frequently updated routing tables.

My personal summary of this discussion so far is the following:

Early adopters of LISP would need to use non-mapped ("legacy") prefixes
in addition to mapped prefixes.  The continued existence of non-mapped
prefixes, in turn, would defeat much of the purpose of the mapping.

Specifically, the existence of non-mapped prefixes would imply...

for provider-DEPENDENT non-mapped prefixes
- limited TE capabilities
- network reconfiguration overhead during rehoming

for provider-INDEPENDENT non-mapped prefixes
- no decrease in the size of the global routing table
- no decrease in the update frequency of the global routing table

A second problem is that, when initiating a communication session, a
host would have to select the correct type of IP source AND destination
addresses.  Non-mapped addresses must be used if either side does not
support LISP.  Mapped IP source or destination addresses should be used
only if both sides support LISP.

The address selection therefore depends on whether...

- the host's own edge network is LISP-enabled
- the (remote) correspondent host's edge network is LISP-enabled

Related to this is the problem that, if a host has multiple addresses to
choose from, there is no way to tell which ones are mapped and which
ones are non-mapped.  This applies to selecting an IP source address
amongst the host's own addresses as well as to selecting an IP
destination address from the set of addresses of the correspondent host.

Extensions to DNS may solve this latter problem.  But DNS is not the
only way in which hosts obtain addresses.  E.g., you have address
references in application layer protocols (-> referral problem).

- Christian



Mark Handley wrote:
> On 8/2/07, Robert Raszuk <raszuk@juniper.net> wrote:
>> David,
>>
>> But what would be the trigger ? What makes a critical mass that anyone
>> could stop advertising their addresses into DFZ ?
> 
> It seems to me that the problem is basically disaggregation, which is
> reasonably closely related to multihoming.
> 
> One scenario is that LISP-enabled sites actually get proper
> multihoming (so long as both ends are enabled), but non-LISP sites
> increasingly find that their long-prefix routes are filtered by ISPs
> that buy into LISP.  It's not that non-LISP sites are unreachable;
> it's just that they're only reachable via the aggregated path, and
> their multihoming doesn't work the way they wish.
> 
> A possible early stage of such a transition plan might involve LISP
> sites continuing to advertise their existing long prefixes for their
> multi-homed customers, but marking them with a transitive attribute
> that says "you may drop this route if you do LISP".  Thus LISP-enabled
> networks have smaller routing tables than non-LISP networks.  After
> enough LISP sites exist, they can also start filtering routes with
> long prefixes that are not marked in this way.
> 
> Anyway, it's premature to fixate on the details of this at this stage;
> the point is that there are transition paths that don't involve making
> prefixes unreachable but rather make then suboptimally reachable.
> 
>  - Mark





--
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