Subject: Re: multi-homing vs route aggregation (was Re: Bad routes update)

From: [email-masked] (Aaron Dewell)
Date: Wed, 21 Jul 1999 10:47:25 -0800 (AKDT)

Why not just call that the cost of doing business in the default-free
zone?  If you choose to put your router/organization there, that has
some costs X associated with it.  It also has other advantages
(reliability, speed, etc.) that come with it also.  Those advantages
have costs.  The fact that others (the end-networks) have influence
over what those costs are is not relevant.

Seems to me wanting people to pay for the resources of being in a better
position is kindof ... greedy.  Anyone who is part of the backbone has a 
business reason for being there, and needs to pay the cost of that reason.

Having the providers who reap the benefits of being there **is** the only
reasonable long-term way to ensure that we can continue to accomodate that
kind of behavior.  ;-)

Aaron

Robert Honore <[email-masked]> wrote:
 > It is both.  Even if you were to compel people to pay the cost of adding more
 > routes, what are you going to do when a large mass decide they are willing to
 > pay whatever price necessary?  If a resource is over-subscribed and you have no
 > way to extend or increase it, you will have no progress.  In fact you will have
 > a large mass of unsatisfied consumers who will go looking for something else.
[...]
 > Having the users of the network pay the costs associated with adding the new
 > routes **is** the only reasonable long-term way to ensure that we can continue
 > to accommodate that kind of behaviour, but I believe that by the time we have
 > figured out the full cost of injecting additional routes like that we would have
 > gone a long way to solve the technical issue as well.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Honore <[email-masked]>
Date: Wed, 21 Jul 1999 16:43:03 -0400

Dear Aaron,

> over what those costs are is not relevant.

That is fine, but the real problem comes up when the end-network sites decide
they too want to become multihomed.  The site that wants to become multihomed
and have its routes propagated above that site's proper aggregation providers
should pay something for each additional route it wants propagated past each
provider.  
 
> business reason for being there, and needs to pay the cost of that reason.
Certainly, and each end-site that wants to propagate additional routes through
this backbone provider incurs an additional cost for each additional route.  Why
should the end-site not pay that cost.
 
> reasonable long-term way to ensure that we can continue to accomodate that

Yours sincerelyl,
Robert Honore.

---

From: Aaron Dewell <[email-masked]>
Date: Wed, 21 Jul 1999 13:35:51 -0800 (AKDT)

> should pay something for each additional route it wants propagated past each

They do pay.  They pay their BB provider for service.  You're
saying the other BBs should be paid also, which I think is
wrong.  By virtue of being a BB provider, they have a certain
commercial advantage.  Advantages cost money.  To play in that
market, they should maintain that infrastructure (and costs).
If they can't, they aren't in the backbone market.

Backbone providers charge more money because they are the
Internet backbone.  Running a router with a *large* quantity of
memory is part of being in the default-free zone.  You want to
have them charge more money for better connectivity (which they
have), but have it not cost them anything to provide that.
Wrong.  All services have a cost to provide, this is one of
them.  This cost is not the responsibility of the end-site, it
is a cost of doing business in that market.

 > should the end-site not pay that cost.

Because the ones getting the bonus are not them.  They shouldn't 
pay, that is a service provided by the backbones so they can
provide backbone service.  No, the end-site should not be paying 
to propagate routes.

_______________________________________________________________________
|Aaron Dewell			===>		[email-masked]         |
|http://www.woods.net/~acd			http://www.woods.net/ |
|PGP keyid 0x0D12A6B9 available from http://keys.pgp.com/	      |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Robert Honore <[email-masked]>
Date: Wed, 21 Jul 1999 18:54:19 -0400

Dear Aaron,

> wrong.

The sentence that runs, "The site that wants to become multihomed ..... should
pay something for each additional route it wants propagated past each provider",
should have read, 

"The site that wants to become multihomed and have its routes propagated above
that site's proper aggregation providers should pay something for each
additional route it wants propagated past its provider."

Now if i have end-network site A and this site is multihomed and directly
connected to two distinct NLA, TLA or provider sites B and C, what is wrong with
paying B if the site A wants to propagate additional routes through B, and what
is wrong with paying C if A wants to propagate additional routes through C? 
Remember this is an end-network site.  Normally he is supposed to be singly
connected and cannot act as any kind of transit network.

You cannot deny that there is a cost for B and C to accommodate site A.  Even
though it may be very small, that cost is still real.  Nobody compelled site A
to seek to become multi homed.  They do experience a benefit from being
multihomed.  That benefit also comes at a cost.  Note I am **not** advocating
that payments be made to any providers  to which the end-network site is not
**directly connected**.

> provide backbone service.  No, the end-site should not be paying 

Yours sincerely,
Robert Honore.

---

From: Aaron Dewell <[email-masked]>
Date: Wed, 21 Jul 1999 15:09:08 -0800 (AKDT)

> connected and cannot act as any kind of transit network.

End-network includes ISPs, frankly.  ISPs and corporate sites
look the same.  Your argument precludes smaller ISPs (those that 
cannot qualify for a TLA) from multihoming.

I believe that Perry brought up that point - that this practice
will encourage folks to pretend they are much bigger than they
are in order to have the privilege of being multihomed.  "Folks" 
in this case referring to ISPs who are not multi-state.

I see your argument for corporate sites, but I still don't agree 
with it.  Should MicroSoft not be multi-homed?  IBM?  The point
is debatable in those cases, but not for ISPs.  ISPs need to
multihome because they are in the business of providing
absolutely reliable service.

 > that payments be made to any providers  to which the end-network site is not

I'm not denying there is a cost.  I'm saying that cost is part
of doing business in that market, that it shouldn't be passed
on.

They are paying for being multihomed.  They pay two providers
instead of one.  One provider would (presumably) charge them
less for the same (total) bandwidth.  Two providers will charge
them more.  There is their extra costs.

I am also not saying that anyone should be able to be multihomed 
for free.  I'm saying that those who do should not be
subsidizing the basic business costs of the BB providers.  That
would be like me asking my customers to each pay $10 for rent on 
my office space.  Clearly, they would not do that.  Same if a BB 
provider asks it's peers (or the end site, it comes to the same
thing) to pay a portion of the inherent costs of being a BB
site.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 1999 08:51:06 -0500

This thread is definitely off in the long weeds IMHO.

What we (the IPNG WG of the IETF) can do is design a technology
that allows ISPs to support multihoming and prefix updates
without punching holes in the TLA and subTLA aggregates.

It really isn't under our control whether they choose to use this,
or prefer to shoot themselves in the feet by continuing to
apply IPv4 practice to IPv6. 

Let's just design the technology here, and as itojun said we made
some progress on that in Oslo.

  Brian

---

From: Ramin Sepehr Rad <[email-masked]>
Date: Thu, 22 Jul 1999 19:16:24 -0400 (EDT)

> without punching holes in the TLA and subTLA aggregates.

I don't exactly know what you mean by "prefix updates", but it sure sounds
like an idea that I have been thinking about to solve the multi-homing
problem.

The idea is that each multi-home site decides on a primary prefix and each
host on the site has only one IP address from that block. However, the other
routers which are connected to other upstream provider use the secondary
prefix and they would do a prefix translation if necessary. (Similar to NAT,
yes I know I just announced my death wish.)

A drawing might help:

    ISPA (2001:ABC::/32)             ISPB (2001:DEF::/32)
      |                                 |
      |                                 |
      R1                                R2         
      |                                 |
  ____|_________________________________|_________
         2001:ABC:1000::/35

Say router 1 (R1) is the primary router (i.e. 2001:ABC:1000::/35 is the
primary prefix). Then R2 has to act as the secondary and do prefix translation
from 2001:ABC:1000::/35 to say 2001:DEF:F000::/35.

This way, a host doesn't need multiple IP addresses so we don't have to worry
about connection scalability and session stability.

However, we do have to worry about the problems that NAT folks are facing.
But not all of them, since prefix translation will be an isomorphic
(one-to-one) translation, we don't have to worry about things such as, DNS
caching, etc.

-ramin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 1999 20:43:49 -0500

Ramin,

You have essentially re-invented GSE which proposed on the fly
prefix translation (except that the prefix was known as routing
goop). The current plan is simpler: if the site has N prefixes,
every host on the site has N IP addresses. This works without
any need to rewrite prefixes.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]