Re: Transport level multi-homing a structural view.

[Brian E Carpenter <brian@hursley.ibm.com>]

Greg Maxwell wrote:
> 
> We must first establish whether or not multihoming belongs above the
> network layer.

Well, no, first we must agree on requirements independent of that
question. But anyway...

> I argue that:
> 
> IP is about transporting packets. The address does not just define a
> host, it also defines the path to reach the host from a common root.

No it doesn't. The path is defined implicitly by the distributed state
of the routing system (and in the case of IPv6, of the neighbour discovery
system on the final link). The address tells you nothing about the path
explicitly.
> 
> The network can not scale if we pollute the network with
> unaggregateable routes. IPv6 has even more potential for pollution then
> IPv4 if handled the same way. Only a relatively small percentage of edge
> networks need to be multihomed to seriously pollute the route tables.

I'm not sure it is relatively worse except for the brute force of larger
scale; but we agree. If multihoming punches holes, the current BGP
explosion will continue.

> 
> There is no reasonable way to globally multihome at the network layer
> without polluting the global routing table. 

That is an interesting assertion but I don't think it's true. When we get
past the requirements stage, we can go into this.

> A simple order of magnitude
> reduction (if even possible) is not even sufficent, future growth and
> other capabilities (such as anycast, multicast, etc) may need the router
> capacity.

Not sure what you are saying here. At the moment we seem to see one new
hole per new multihomed site. Would log(N) growth be OK? Would it be OK
if all additional routes created by multihoming aggregated perfectly (i.e.
if we have N ISPs with a million multihomed customers each, we see exactly N
aggregated routes)? What is the exact target?

> Multi-homing at a higher layer (such as in the transport) increases
> flexibility, reduces network state, and improves end-to-endness.

And will not provide backup connectivity for legacy apps, and will 
therefore cause today's style of IP multihoming to be used anyway.

> *Changing to end-to-end multihoming after IP multi-homing is established
> will be virtually impossible because of the massive structural
> differences, to an even worse extent then unaggregated IPv4 routes.*

You've got it. But the inertia here is *not* in the IPvN stack. It's
in transport, APIs, and applications that the IP version hardly
affects. We are *already* stuck in this situation.

> Because of these reasons, all long-term survivable global multi-homing
> solutions must be implimented above the network layer and pollution must
> be prevented from the start.

Survivable transport solutions can *only* be implemented above the network
layer, so we can't argue there. And we need a way to avoid punching holes
in BGP, so we can't argue there either. I just think they are two
separate issues with separate solutions.

   Brian

> 
> How might it look, network wise:
> 
>     [Tier 1 - provider & TLA][Tier 1 provider & TLA]
>      |                      *
>     [Tier 1 - provider & TLA][Tier 1 provider & TLA] - [Tier 1 ...]
> 
> (an arbitrary mesh of tier 1 providers,
>  route table size is their coustomers +
>  number of links to other tier 1s
>  routing capacity scales with links)
> 
>     [Tier 1 - providerB & TLA][Tier 1 providerC & TLA]------------------\
>      |                      *                                           |
>     [Tier 1 - providerA & TLA][Tier 1 providerD & TLA] - [Tier 1 E ...] |
>     |      |                    |   |                        |  |   |   |
>     \     [tier 2 A prefix ]\   |   | /----------------------|  |   |   |
>     [cust sngl homed A] |  ||   |   [Tier 2 - D&E prefixes]     |   |   |
>     [multihomed cust A&D]--uu---/    | \[Cust D&E]   [Cust E]---/   |   |
>     [cust sngl A]----------/|        |    /[Link Sharing cust Pre E&C]  |
>                 [Tier 3 provider A&D&E]   \[Link Sharing cust Pre C&E]--/
>      [Cust A&D&E]/ \[Cust A&D&E]-----private IP level peering--/
> 
> Notice how this is so structurally differnt from today's network layer
> multihomed network. Also notice the ability of customers to link share
> without any provider asstiance, they just need to give each other some of
> their address space. Tier >1 providers don't multihome.... They pass their
> multihoming on to their customers.
>