Re: [RAM] The mapping problem: rendezvous points?

[Tony Li <[e-mail]>]

Dave,

> Renumbering doesn't incent the host to change.  As I mentioned in the
> Intarea presentation, renumbering requires MANY components to change
> (hosts, firewalls, IDS's, enterprise inventory applications, etc.)


Understood, but perhaps I'm being unclear.  I'm referring to removing  
the *need* to renumber by making site addressing independent of the  
provider.  Specifically, if we do a locator/ID split properly and  
propagate it through the architecture, then filtering mechanisms can  
be done based on identifier and not locator.  Subsequent renumbering  
events then become cheaper.

This is a significant benefit to the site, and thus is a significant  
incentive to the host.

I should also note that this argument holds as long as the loc/ID  
mechanism has any functionality within the site.  If the LISP ITR/ETR  
is anywhere within the site, for example, this is relevant.


> Changing hosts by themselves doesn't solve anything... we learned this
> from IPv6.


Correct.  That's what we're here to fix, in my perspective.  We need  
to change the network architecture and just changing the routing  
plane without a coordinated change from the hosts doesn't do that.


> Mobility incents _some_ hosts to change... but just the ones that are
> mobile.


I heard that something like 60% of all computers being sold today are  
laptops.  Given WiFi, EVDO, WiMax, etc., I would think that the host  
would want to make the best possible use of mobility.  And fixing 60%  
of the systems out there seems like incentive.


> That's why Mobile IPv6 has an easier deployment model than say HIP...
> with MIPv6 someone who changes still gets benefit (with help from a
> Home Agent) when talking to arbitrary correspondent nodes.  The
> correspondent nodes aren't strongly incented to change, and don't have
> to.


No argument, but it seems like the suboptimality introduced by the  
triangle routing problem might provide some encouragement to change  
the host.

Tony

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram