Re: Re: Draft of updated WG charter

[Dave Crocker <dhc@dcrocker.net>]

Jay,


>  On Fri, 9 Jan 2004, vijay gill wrote:
> >  Routing update validation should be orthogonal to the multihoming
> >  solution.  Also, I am going out on a limb here and say that any
> >  m-homing solution that requires end-host updates is a non-starter
> >  from the get-go.
>  
>  I'll go further out on that limb & say that any multi-homing solution which
>  requires substantially more intelligence in end systems than is currently
>  required for multi-homed IPv4 is bound to fail, even if you somehow get it
>  deployed.

These two forays into limb-walking seem important enough to warrant explicit 
descriptions of their baseline references.  If I missed these on the list, 
please point me to them.

For example, by "end host updates" do you mean that end hosts should hold no 
state about multihoming but that, instead, it must be done entirely in the 
routing infrastructure?

This is not a small point.  There is a line of thinking which suggests that the 
routing/router infrastructure should not be changed at all -- the basic packet 
transfer service works too well to mess up -- so that multihoming is strictly a 
value-added function done strictly in the end hosts. (Small concession:  
organization gateway routers, for site multihoming, are certainly distinct from 
end hosts, but they are also distinct from the general infrastructure.  Yet they 
are a good candidate for implementing multihoming.

And what is the summary description of the intelligence currently required for 
v4 multihoming?


 >  This is really the heart of the IPv6 scalability issue.  I've never
>  understood the argument that multi-homing for IPv6 ought not be done the 
>  way it's done for IPv4 (single address per end system, multi-path routing) on
>  the basis that the network can't tolerate the increase in routing table
>  size/complexity. 

Well, one argument is that it requires an entirely new type of addressing, since 
pure topology no longer dictates the address.  And that level of change to the 
infrastructure is one worth trying to avoid except under extreme duress.


>  My objection is that the alternative (shoving the
>  complexity to the end systems) is much worse because:
>  o  as evidenced by worm attacks..., the end systems are the worst managed
>  pieces in the whole puzzle run by users who don't (& I'd say shouldn't
>  be expected to) understand the workings of the network;  predicating
>  routing-type functionality on that platform is asking for trouble

It depends on the nature and degree of the routing work done by the end host, 
and how much administration is required for it.


>  o  there are at least 3 (4? 5?) orders of magnitude more end systems than
>  there are routers, so embedding significant pieces of networking
>  functionality in end systems greatly increases the likelihood of
>  trouble 

And requiring the infrastructure to change before a function is useful tends to 
require 3 (4? 5?) orders of magnitude more delay.


>  I advocate keeping the end systems as simple as possible & dealing with the
>  routing support required to make multi-homing work close to the way it 
>  works
>  for IPv4.

Hmmm.  Simple end system components, complex network components.  

Isn't that the phone system approach, and rather pointedly divergent from the 
historical Internet approach?

d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>