Re: A new spin on multihoming: multihoming classes.

[smd@ebone.net (Sean Doran)]

I think we would like to solve the problems for ANY site 
that is trying to multihome with IPv6, although there may
be several different and possibly co-existing solutions
available at the end of the day, just as there is with IPv4.   

Trying to restrict our scope to just some types of sites
will lead into quasi-legalistic arguing about what a site
is and whether a small server farm or a soho is really
a site in the sense of e.g. 2.5.4 of draft-ietf-ipngwg-addr-arch-v3-06.txt.

In other words, feel free to propose solutions which are
optimized for certain types of sites, as long as such
solutions do not exclude (or refuse to interoperate with)
either a more general (set of) solution(s) or different
specific solutions for different types of multihomed sites.

Personally, I prefer more general solutions since assumptions
about the traffic profiles and even protocols that any given
entity (particularly ones that are not huge aggregators of traffic) 
tend to be surprisingly short lived.

| - Entreprise class is for companies that receive a BGP
| feed from two different TLAs and have been allocated a
| centrally managed multihomed block of IPv6 addresses.

Incidentally, I also (personally) prefer solutions which DO NOT require the
use of BGP.  Operational complexity aside, lots of sites means
lots of ASes, which do not aggregate away even as nicely as
the prefixes they originate (and we do not want to juggle private-use ASes).
If all sites are to have some sort of site-identifier, these
should be directly associated with the topological location
part of an address, rather than indirectly as an indication
of originator and a reannouncement-loop-prevention device in the
rather crusty exterior routing protocol in use today.

One method for doing this more directly would be to have the
RoutingGoop in an 8+8 like system be an encoding of higher-order
routing objects (abstracted collections of sites, which in turn
are abstracted collections of links&nodes) into the top 8-or-so
bytes of an address.  However, as people have been discussing here,
this does require either that the hosts be much more aware of
their exact topological location(s) or that they be much more
agnostic about them than they are with current IPv6 host implementations.

Ran Atkinson, for example, has done a little bit of list-making
about what would have to change for a host implementation to 
generally not care about what its own top 8 bytes are, and this
includes some obvious things like header & pseudo-header checksumming,
and some less obvious things as well.

Other folks here have proposed something along the lines of "pushing down"
SCTP ideas into the stack, for the benefit of all applications, or
alternatively having hosts adapt to addressing changes that the other
hosts they communicate with undergo.

Few of these proposals are specialized to site types per se, and
few of them propose having hosts partcipate directly in the global
routing system to the extent of being fully aware of non-local 
(and not immediately relevant) topology changes nearly as they occur.
In my (personal) opinion, these are strengths, although I do agree
with you that there are "cheaper" ways of attacking specific site types.

	Sean.

p.s.: thank you for the pointer to your draft;
      i'm sure that if it makes a convincing case for attacking your
      enterprise site type specifically, that some way will be found
      to carry the work forward towards the standards track (and more
      importantly, real world implementation)