Re: Re: Draft of updated WG charter

[Jay Ford <jay-ford@uiowa.edu>]

On Fri, 9 Jan 2004, Dave Crocker wrote:
> 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?

Pretty much.  If hosts have a single address (as most do in IPv4), they don't
need to even know that they're multi-homed.

I view *sites* as multi-homed, not hosts.  Therefore, I view the problem of
how to make multi-homing work at the site (usually AS) boundary with other
entities (ASes), not how to make the individual hosts do it.

(Granted, some individual hosts are multi-homed, within a single site or even
among multiple sites, but I suspect that they are the exception & could be
handled as one-off cases.  Such hosts already have to be aware of networking
to choose the next IPv4 hop, so they could choose the next IPv6 hop in a
similar fashion.  Regardless, they are not the vast majority which are
single-homed within a single site.)

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

I guess I'm closer to the other end of the spectrum.  The routing
infrastructure should deal with most of the burden of getting packets to
destinations as efficiently as possible.  The hosts shouldn't be expected to
do that job, because they are ill-equipped to do so.  They should focus on
layer 4 & up.

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

In the common case where the site (not the host) is multi-homed, the host
needs to know very little.  It usually has a single source address & a single
next hop router to which it sends all packets.  The destination address is
chosen by some means (DNS...), but the host doesn't try to figure out which
destination address is "best".  It also doesn't have to choose a source
address because it has only 1.

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

For many sites, topology doesn't dictate the address in IPv4.  I have 2 /16s
which I announce to those with whom I connect.  The topology is dictated by
the links & the routing announced on them, not by the numeric value of my
addresses.

I realize that cranking the dial up from 32 to 128 raises serious concerns
about the ability of the routing infrastructure to handle
non-connectivity-dependent or non-provider-based addressing.  However the
discussions I've seen about IPv6 address usage lead me to believe that there
won't be anywhere near 2^128 routed prefixes.  With common prefixes of /64 &
shorter for "sites" (university campus nets, corporate nets, ISP clouds...) &
the loss of a few "formatting" bits, we're probably talking 2^60 as an upper
bound.  I'm not saying that 2^60 isn't a huge number, but it's closer to
surmountable than 2^128, and with gradual roll out we probably wouldn't see
more than a small fraction of those for a long time.  I'd prefer to try to
tackle routing for 2^60 prefixes than to predicate the operation of the IPv6
Internet on how well hosts choose source/destination addresses => paths
through the network.

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

Based on what I've seen of how poorly hosts are defaulted & administered, any
increase in complexity & responsibility placed there is a bad thing.

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

Really?  It seems that I could upgrade my O(10) routers before any
significant fraction of the O(10k) hosts on my campus could get upgraded.

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

I think it depends on where you divide the responsibility.  My division is
that the complexity of layer 3 (IPv4 & IPv6) ought to be in the network, &
the complexity of layer 4 & up ought to be in the hosts.  Sliding that line
down to make the hosts responsible for layer 3 seems like a recipe for
disaster.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951