Subject: Re: [arch-d] RE: Ok, so what should we do then?

From: "Fergie" <[email-masked]>
Date: Tue, 14 Nov 2006 04:32:06 GMT

Sorry for top-posting, but wanted to retain the context of this.

Geoff Huston mentioned something very similar to this to me
last week (actually, it was more like "Tell me how crazy this
sounds..."), but basically, the tunnels would forward based
only on AS path found in the BGP path, per prefix, and not the
RIB, from tunnel-endpoint to tunnel-endpoint.

Before I butcher his idea, perhaps Geoff would care to expand on
it himself.... 

- ferg 

-- <[email-masked]> wrote:

How about limiting DFZ only for provider aggregatable addressing and
using some on-demand routing and tunneling over the DFZ for PI prefixes?
Initially this tunneling could be over existing IPv4. This could be
pretty much like some of the tunneling based IPv6 transition methods,
but you keep tunneling even if the DFZ transfers to IPv6.

The border (where the tunneling happens) does on-demand lookups for PI
destination addresses and caches the results. Reverse DNS lookups would
work fine, as long as the PI addresses have prefixes that aggregate on
organizational + some regional structure. Outside of the DFZ the PI
addresses would be routed (internally) and packets with foreign PI
destinations would be default routed towards DFZ.

Some sites having too much peers to cope with number of tunnels would
use just provider based addressing (e.g. content distributors) and cope
with renumbering. That way the tunneling state would distribute to
content servers and could be manageable on the side of the transport
protocol context.

In summary the proposal is to keep DFZ provider based only, and have PI
addressed traffic tunnel over it, forever. This will happen naturally as
an outcome of the IPv6 transition, if we keep the IPv6 DFZ free of PI
addressed routes, as the tunneling mechanism is needed to IPv6
transition over IPv4 anyway.

Regards,

	Jarno

[snip]

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss