Subject: Re: A new spin on multihoming: multihoming classes.

From: [email-masked] (Sean Doran)
Date: Wed, 5 Sep 2001 20:00:39 +0200 (CEST)

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)

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Wed, 5 Sep 2001 12:28:04 -0700 (PDT)

Sean,
> the prefixes they originate (and we do not want to juggle private-use ASes).
I don't think every site needs an AS number even though we use BGP.
For example, in my draft
(http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt), we
*don't* need a multihomed site to have an AS number. Only (multihomed)
ISPs are required to have an AS number.

> rather crusty exterior routing protocol in use today.

In my draft, loop-prevention, etc., is detected by bgp routing attributes
associated with route withdrawals and not by AS numbers or other
site-specific identifiers.

thanks,
ramki

---

From: Geoff Huston <[email-masked]>
Date: Thu, 06 Sep 2001 08:06:33 +1000

>available at the end of the day, just as there is with IPv4.

I'm reminded of the parable in Marshall Rose's "The Open Book" (ok - yes, 
it was some years back) about the toaster, where the king wants a toaster 
and the Standard's response goes along the lines of "Ahh, but you are 
forgetting that toast is but one class of breakfast foods!".

To me there is some value in restricting and dividing the problem space, 
rather than generalizing it to the point where standards-based solutions 
start to loose traction.

There is some merit, in my humble view, of looking at the stub 
(non-transit) routing domain that is multi-homed, and looking at the 
interaction between the stub's exterior gateways and the interior hosts to 
see if a) the exterior gateways can conform to the address hierarchies that 
are derived from the external connection, and b) these address prefixes can 
be used by the interior host (in some fashion)  so that the stub network 
and the hosts do not rely on the current (v4) technique of punching small 
address prefixes into the global routing soup.

There is also some value is looking at a discrete problem set where a 
single host, or a non-routed enterprise LAN is dual homed into two or more 
provider networks, and the communication with the edge devices of the 
providers' networks is, perhaps, more restricted.

The more general issue of multi-homed networks when you include both 
transit and stub domains may require somewhat different approaches to solve.

  Geoff

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 5 Sep 2001 18:03:52 -0700

> providers' networks is, perhaps, more restricted.

What is the point? Odds are very high that the small site will 
grow in complexity over the lifetime of the mechanism we define
here. If we don't build a mechanism that ignores the size of
the multi-homed site, we will simply create an operational 
problem down the road in transitioning all the sites from one
mechanism to another as they grow.

Tony

---

From: Michel Py <[email-masked]>
Date: Thu, 6 Sep 2001 17:09:25 -0700 (PDT)

Sean,

>> draft-ietf-ipngwg-addr-arch-v3-06.txt.

I was not trying to restrict the scope of the
workgroup but
try to describe the problem so everyone has the same
reading
on it. For what I have read here for the last three
days, the
two cans of worms that Ilsitch and I have opened did
not leave
people indifferent.

>> specific solutions for different types of
multihomed sites.

That makes my point: Until the perfect and universal
multihoming
solution is invented, this workgroup is the best place
to ensure
that all classes of multihoming not only can coexist
but are
aware of each other.

I think that everyone would benefit from guidelines in
the
requirements draft such as:
- There are roughly 3 classes of multihoming:
entreprise, user
and mobile (with some flexible definitions). If your
draft is geared
to only one or two of these, please make it clear in
the text.

BTW, when do we see a requirement draft?

>> tend to be surprisingly short lived.

So do I, when they exist.

>> Incidentally, I also (personally) prefer solutions
which DO NOT
>> require the use of BGP.

I have heard many times that the only multihoming
solution some
people would accept is BGP-based and preferably a slow
evolution
over the IPv4 deal.

>> Operational complexity aside, lots of sites means
>> the prefixes they originate
>> (and we do not want to juggle private-use ASes).

My IPv6 home network is kinda-multihomed (I have two
blocks but no
multihoming solution, sigh) to two different 6bone
pTLAs
using a private ASN and I don't see anything wrong
with that as long
as the pTLAs do not advertise my ASN but theirs. In
the case of
MHTP, that would not be a problem at all.

>> If all sites are to have some sort of
site-identifier,

We don't all wear the same shoes because we don't all
have the
same feet and I think that there is nothing wrong with
some sites
using their ASN as the site-identifier and some other
sites using
some other mechanism, because their multihoming
requirements are
not the same.

Michel.

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

From: Michel Py <[email-masked]>
Date: Thu, 6 Sep 2001 17:28:32 -0700 (PDT)

Tony-

> If we don't build a mechanism that ignores the size
of
> mechanism to another as they grow.

This is true, but keep in mind that a bad solution is
better than
no solution. There are people that don't want to adopt
IPv6 today
because there is no multihoming solution.

Michel.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 Sep 2001 09:23:16 +0300 (EEST)

On Thu, 6 Sep 2001, Michel Py wrote:
> This is true, but keep in mind that a bad solution is better than no
> solution. There are people that don't want to adopt IPv6 today because
> there is no multihoming solution.

I'd like to disagree.  I think, for most people, this is just a _good
excuse_ not to adopt IPv6; they really don't want to yet, as there is
little incentive other than being on the cutting edge, and preparing for
the days when clients start to enable IPv6.

There are ways if people _really_ wanted to get to IPv6.  For example, get
multihomed IPv4 connectivity and run tunnels over each of them.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Sep 2001 12:33:37 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    >> there is no multihoming solution.

    Pekka> I'd like to disagree.  I think, for most people, this is just a _good
    Pekka> excuse_ not to adopt IPv6; they really don't want to yet, as there is
    Pekka> little incentive other than being on the cutting edge, and preparing for
    Pekka> the days when clients start to enable IPv6.

    Pekka> There are ways if people _really_ wanted to get to IPv6.  For example, get
    Pekka> multihomed IPv4 connectivity and run tunnels over each of them.

  Ah, that's the rub.
  Getting multihomed IPv4 connectivity is a lot harder than getting IPv6.
  (Believe me. I've been involved in getting the groundwork layed in place at
multiple mid-sized regional ISPs in order to convince the powers-that-be to
allocate an AS#)

  In my talking with these ISPs, they see essentially no reason for them to
risk any of their network to deploy IPv6. Particularly since 6to4 lets their
customers do it whenever the customer wants. The customers mostly do not care
about IPv6 either, but they wish they could multihome themselves easier. Most 
have multiple xDSL and 10Mb ATM VCs, but have all sorts of hacks to permit
them to make the most use of the bandwidth and redundancy.

  This is why I object to any solution that has different classes. Nearly
every single one of these ISPs went from stack of {SCO,Solaris,Xylogics,BSDi}
and modems plus T1 to OC-3+,etc. The customers went from "soho" operations
with a single high-end Sparc 2 or 486 to racks and racks of equipment. I
think that this is the story of the rest of the Internet as well. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Michel Py <[email-masked]>
Date: Fri, 7 Sep 2001 17:14:10 -0700 (PDT)

--- Pekka Savola <[email-masked]> wrote:
>>>> This is true, but keep in mind that a bad
solution
>>>> is better than no
>> I'd like to disagree.  I think, for most people,
>> this is just a _good excuse_ not to adopt IPv6;
>> they really don't want to yet, as there is

I agree with that, but the fact that the lack of
a multihoming solution is used as an excuse does
not change the outcome.
 
>> There are ways if people _really_ wanted to get to
>> IPv6.  For example, get multihomed IPv4
connectivity
>> and run tunnels over each of them.

Yep, using 6to4 tunnels. Which makes the problem
worse,
because if they can multihome IPv4 most will find
plenty of excuses to delay IPv6 deployment.

Michel.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 8 Sep 2001 15:04:45 +0200 (CEST)

> multiple mid-sized regional ISPs in order to convince the powers-that-be to

Strange, I've never had much trouble getting an AS# from RIPE.

> them to make the most use of the bandwidth and redundancy.

So then if we can come up with a good multiple addresses / host
multihoming scheme, it might be worth the trouble to see if we can get it
to work on IPv4 too.

Or why stop there. Let's make something that runs over both IPv6 and IPv4
at the same time.