Re: Transport level multi-homing a structural view.

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Wed, 4 Apr 2001, Brian E Carpenter wrote:

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

Right. I'm sorry. I was nesting the use of first beyond our current state.

I think it's useful to discuss transport level multihoming now because it
helps frame the requirements. (Would we be discussing TCP session falure
so much as a result of link falure if non-network level multihoming was a
serious consideration).
 
> > 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 exact path, the physical links are, but a network spatial topology is
defined by the network portion. The mapping to physical links within that
topology is dynamic.

For example, my address at home is:

Gregory Maxwell
5533 SE Avalon Dr.
Stuart Fl, 34997-8557

This says nothing about the route required to reach me, but it specfically
defines a singular (provided the delivery agent is a robot :) ) path to me
'Gregory Maxwell' within the relative knoweldge context, that is..

"Gregory Maxwell" doesn't mean squat to a post office in California nor
does "5533 SE Avalon Dr." but 3 means send it to the south east, 4997 says
send it to my local post offic.. From there "Gregory Maxwell" is
meaningless, but they can map -8557 into a path a truck takes. The driver
drops the mail at 5533 SE Avalon Dr. and the people there know about 
"Gregory Maxwell".

Intrestingly enough, I have postal multihoming.. Above the network layer
too. If my family members looses my address at home (happend right after I
last moved..) or my local post office is distroyed (?), they could reach
me at work 34996:3322:MontereyRD:2401:ITS:Gregory.Maxwell. This requires
no pollution of the postal routing table and would work equally well if I
lived in calafornia.  Fortunatly, my junk mail is not self-multihoming.

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

Certantly.

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

Yes.. I should have been more specific here, I think I've stated it
before: Space (route table size), Time (convergence, cpu load), and
bandwidth.  If you are able to make space scale at the expence of time and
bandwidth then I don't think you have improved things much.

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

Right. Perfectly aggregatable at the global level should be the largest
goal. Improving it at sub-levels should be important too, multihoming
would ideally do nothing to break aggregation anywhere.

Log(n) growth would be acceptable. More ideally, It would be nice to have
a solution where the highest level routing table had on the order of 
<=1,000 unicast routes in say, 20 years, and where lower level providers
don't have any more routes then customers. Lower level providers should
not have more then providers*customers routes. 

Routes = (fixed small N) * customers is a nice number for providers as
customers pay their way directly.. One providers increase in customers
wouldn't have any routing burden on other providers (or even their
provider!) in the diagram that followed my message. 
 
> > 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.

If it's implimeted in the TCP stack as an option without app visiable
API changes, and is available on most systems when IPv6 starts becoming
popular then I don't follow..

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

My idea was that we should be to get BASIC multihoming in TCP *FAST* (if 
it meets the requirements we are working on..) so that you can prevent
IPv6 from getting this inertia (i.e. if we decide that transport
multihoming is the solution for IPv6 we can totally forbid breaking
aggregation as an acceptable practice).
 
> > 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.

Potentially, but I can't think of any that don't involve increadibly slow
convergence and extra cpu load.

If we decide that the ultimate goal is transports that are able to do
smart multihoming then we should try to make the v6 multihoming solution
highly encourage network designers to make their networks compatible with
a transport level multihoming.

(like my 'flow through' prefixes in the ascii art).