RE: draft-kurtis-multihoming-longprefix comments

["Tony Hain" <alh-ietf@tndh.net>]

Tony Li wrote:
> |   The 
> |   forced address
> |   change approach simplifies routing by moving the complexity to the
> |   endpoints.
> 
> 
> You say that like it's a bad thing.  

Not intentionally. It was just a statement that the complexity has been
moved, not removed.

> ...
> |   I understand how they did it (my desk phone has a Bellevue 
> |   & San Jose
> |   number), the point was that is the type of service Joe 
> |   Sixpack expects,
> |   yet it doesn't scale in the routing system.
> 
> 
> If you understand that it doesn't scale, then why are you advocating
> it?

I bring it up because it is not significantly different than other
mapping schemes that have been proposed. We know it doesn't scale, and
it is only done once at call setup rather than per packet.

> ...
> Yes, they both do.  People still don't like 'em cause they're 
> "not the IP way."

If by 'IP way' you mean that it is a change to the expectations apps
have of the underlying architecture, then I have to agree. It is not
clear to me that 16+16 is visible to apps, so maybe that doesn't apply.

> ...
> We are first trying to achieve consensus amongst those who should
> know a sensible architecture.  If we can say "here's how it will be"
> then selling Joe sixpack on it is much easier.  If we continue
> having to have this same discussion with you for another decade,
> we will not move one iota from where we are today.

You seem to think I am being obstructionist. I am not.

> 
> 
> |   The point is we did not solve the problem, we just moved it. 
> 
> 
> We have no choice but to move it.  Multihoming cannot be solved
> soley by routing without architectural change in a scalable manner.
> 
> 
> |   If the address were independent of 
> |   delivery and
> |   the remote routing mechanism only dealt with cities, Joe's 
> |   would have to
> |   bring it to Seattle to figure out what to do with it.
> 
> 
> And that would be a fine abstraction if that had anything to
> do with reality.  Unfortunately, geographic addressing has
> about as much to do with topological connectivity as common
> last names have to do with street addresses.

And when I am in Japan connecting to home, topological detail of Seattle
has absolutely nothing to do with which service provider I hand packets
to. The fact the destination is Seattle rather than San Francisco might
have something to do with a trans-pacific cable choice, but the cable &
dsl providers are present in both so PA doesn't really help with TE
there. Once the radius is reduced to 1000km, the number of possibilities
increases dramatically, but outside that range there are really very few
choices. Why should all DFZ routers outside that range know the details?


Tony


> 
> Tony
>