Subject: RE: draft-kurtis-multihoming-longprefix comments

From: "Tony Li" <[email-masked]>
Date: Tue, 7 Jan 2003 18:29:19 -0800

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

Correct.  And in some cases, it seems that folks are getting paid
for the feature.

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

16+16 would be very visible to the apps.  In fact, any change that has
independent identifiers and locators would be a change to the apps.  Because they
are not expecting/allowing that.

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

Then please educate me on your position.  What scalable, implementable
solution do you advocate?

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

You're suggesting abstraction that grows with distance.  You may
recall that I proposed that we do exactly this in 1992 with continental
aggregation.  I was shouted down.

This only works because in almost all cases, continents are internally
connected and the number of exceptions is quite small.  Further, over
time, as we wire the planet, even these exceptions will disappear.

So yes, I have no objections to continental scale aggregation.  
Unfortunately, that is not a technique that recurses down to the 
micro level.  We need to work with the connectivity that is naturally
in place and cannot force fit it to suit.

To take your street address metaphor farther, we should not insist
on building bridges across the Grand Canyon just to insure that a
zip code is contiguous.

Tony

---

From: Peter Tattam <[email-masked]>
Date: Wed, 8 Jan 2003 14:06:42 +1100 (EST)

On Tue, 7 Jan 2003, Tony Li wrote:

....

> are not expecting/allowing that.

I have had little feedback on my recent idea.  I am not sure if it is a
duplicate of other work or whether it will even work.  I believe if it works
(i.e.  scales reasonably and is reliable) then it would solve the application
level locator issue as the transport addresses are insulated from the
application socket structures and DNS structures.

....

> Tony

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: David Conrad <[email-masked]>
Date: Wed, 8 Jan 2003 09:59:30 -0800

Tony,

On Tuesday, January 7, 2003, at 06:29  PM, Tony Li wrote:
> independent identifiers and locators would be a change to the apps.

Perhaps I misunderstand, but I don't see why this is the case.

If you assume a border between the part of the network that cares about 
topological significance (that is, the core) and the part that does 
(that is, the end points), then doing mapping/unmapping at that border 
would be invisible to the applications -- the core only cares about the 
locator, not the end point identifier.

For example, assume you throw out the current IPv6 address architecture 
and instead say that the lower 4 bytes of an IPv6 address is an IPv4 
address.  Now, assume reality in the on the non-core side of the border 
gateway, end users use IPv4.  When a packet needs to transit the (IPv6 
using) core, the border gateway does (the moral equivalent of) a 
(dnssec signed, of course) AAAA in-addr-style DNS lookup of the 
destination IPv4 address and synthesizes an IPv6 destination address 
composed of the destination IPv6 prefix returned by the DNS lookup (in 
the top half) and the destination IPv4 address (in the bottom half).  
When the packet hits the destination border, an IPv4 packet is 
synthesized from the lower 4 bytes of the IPv6 address.  If you don't 
want to assume reality, use up to 8 bytes (or more, since we've agreed 
to throw out the existing IPv6 addressing architecture) for the end 
point identifier -- the in-addr-style lookup wouldn't care.

Site multi-homing becomes trivial -- simply add additional prefixes in 
the RR set referenced by the in-addr-style lookup of the IPv4 host.  If 
you want to get tricky, the border gateway could keep information about 
which prefix is best among the ones returned.  Renumbering also becomes 
essentially a non-issue as it can be made transparent to the end users 
since end users are dealing with non-hierarchical identifiers.  
Mobility might also be simplified, although I think there are some 
issues wrt trust boundaries that need more thought.

Of course, this is just an example of how one could implement a 
locator/identifier mapping mechanism that doesn't require apps to 
understand that mapping -- the key is to have a way of doing an 
'unmapping'...

Rgds,
-drc

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 9 Jan 2003 16:01:21 -0800

Tony Li wrote:
> ...
> You're suggesting abstraction that grows with distance.  You 
> may recall that I proposed that we do exactly this in 1992 
> with continental aggregation.  I was shouted down.

That doesn't mean it was a bad idea, just ahead of its time. :)

> 
> This only works because in almost all cases, continents are 
> internally connected and the number of exceptions is quite 
> small.  Further, over time, as we wire the planet, even these 
> exceptions will disappear.
> 
> micro level.  We need to work with the connectivity that is 
> naturally in place and cannot force fit it to suit.
> 
> To take your street address metaphor farther, we should not 
> insist on building bridges across the Grand Canyon just to 
> insure that a zip code is contiguous.

The contiguous requirement only applies to short prefixes. In the case
where it is not possible to make it contiguous, longer prefixes are
necessary. The fact it is not perfect does not mean the whole approach
is invalid, just that it carries a set of engineering trade-off's like
all the others. 

For the sake of discussion, let's assume it is technically, financially,
or politically infeasible to bridge the Grand Canyon. Also that there is
a significant population of multi-homed sites on both sides. This would
lead to all circuits on the north rim routing through Salt Lake City,
while the south rim routes through Phoenix (ignoring the obvious cross
connect through Las Vegas or LA). Further, continental scale aggregation
is done in San Jose, Chicago, and D.C. 

Using the draft I have been working on, there are 18 /24's that would
need a longer prefix exception list. 
See: http://www.tndh.net/~tony/ietf/GrandCanyon.htm
Most of that space would be cleanly described by /26's, where the
conflicts in turn being cleanly broken down by /28's ... The routing
table grows with each exception region, but not at the rate of
multi-homed sites. At the same time, an announcement only needs to be
present if there is a site in the space covered.

The prefix x6C0::/12 covering Santa Maria (west 120w), Santa Ines (south
30n), Denver (east 105w), Wyoming northern border (north 45n),
associates with the San Jose aggregation point. If divided into /14's,
the cut would be through the middle of the canyon about 32km west of
Grand Canyon Village. The Glen Canyon section would be divided about
55km north of the Utah southern border. This leaves the entire /14
containing Fresno, Boise, and most of Nevada contiguous. The other 3 are
mostly contiguous, just needing ~50 /28's to cover the exceptions.

The point is that only providers connecting to San Jose would need to
know the detail. Regional providers in the rest of the world would only
see the x6C0::/12 announcement, if that. They might only be looking at
the ::/6 which identifies the section. Also, it is clear there are other
rivers covering more distance, so this is not meant to claim this is a
worst case, just an exercise to show what would be necessary to address
the premise.

You claim it can't recurse down to the micro level. I disagree, because
it will recurse on whatever scale makes economic sense. When there are
too many exception entries, it will become economically viable to split
the space by putting in more exchanges. The economic driver is the
reason for the current set of exchanges. Historically those have been
driven by circuit costs, but in an environment of capacity glut the
economics change. Either way, you can't avoid flat routing in some
subset of the routers, it is just a trade-off between how many routers
need to know the detail vs. the interconnectivity required to mask that
detail. 

You further claim we have to work with the connectivity that is in
place, which is demonstrably false. Otherwise we would still be routing
through FIX-E&W via government nets or NSF Regional's (or IMPs if we go
further back). Connectivity evolves over time to match the current state
of the players and the economic limitations. While we can't dictate a
connectivity model, we can define technologies that work best with one
or two models, while having the ability to handle exceptions. This is
exactly how we migrated from government sponsored to commercial
networks. It is also the case that even if we found a 'perfect'
technology for the current interconnectivity, in 5 years time that model
wouldn't be perfect anymore because the connectivity underneath it as
well as the policies for traffic management would have changed. If we
can agree on the defining characteristic separating the basement
multi-homer from the global enterprise network, we can define different
connectivity models for each. 

My approach is not intended to be a grand one-size-fits-all technology,
and exceptions showing when PA should be used are discussed in the
drafts. It is simply an approach that leverages current BGP deployments,
and can be scaled in different parts of the world to whatever level
makes economic sense. In the spirit of globalization via the Internet,
it explicitly ignores artificial political borders. This may be a good
or bad thing based on your views about being politically correct. ;)

Tony