[arin-ppml] Rationale for /22

[Ted Mittelstaedt]

Kevin Kargel wrote:
> One quick point on the existance or emergence of small multi-homed
> networks..
> 
> In the past year and a half I have seen a very noticeable increase in the
> number of small organizations that are going or attempting to go multi-homed
> with DSL connections to multiple upstream providers.  They are doing this as
> a means to try and do what they did before with expensive dedicated circuits
> like T1.  Increased reliability of a $39.95 SDSL has led these customers
> down the primrose path to think that if they have a couple of these then
> they don't need an $800 ATM circuit.  
> 
> I am not saying I agree with this philosophy or even that I think it is
> functional, but I am seeing it happen.
> 
> As these customers get educated they figure out that they are technically
> "multi-homed" and that they "can" get their own IP space,

No, they can't because they aren't really multihomed.

> and if they invest
> in a router that can do BGP they can gain transparent (to the end user)
> routing reliability using these DSL connections.

Very few ISP's provide BGP over DSL.  We are the only one in our city
that does, as a matter of fact.

> Bean counters tend to
> prefer non-recurring expenditures to recurring expenditures.  
> 
> These organizations are small hospitals, clinics, small banks, farmers,
> insurance agencies, non-chain manufacturers and distributers, et.al.  They
> don't need a lot of IP, but they do need routing failover.  They are
> learning that it is theoretically (albeit not realistically) possible to do
> what used to require a T1 on SDSL better for a fraction of the cost.  
> 
> I believe we will see a mushrooming incidence of these small multi-homed
> organizations in the routing tables in the coming years.  
> 
> This will affect the issue of global routing table size and does have a
> bearing on reducing the minimum allocation unit.  
>

I don't think so, Kevin.  The main reason for this is that all of the 
small "2 DSL multihomed" routers that are on the market operate on
the same principle, they expect 2 DSL lines that are PPP-mode DSL.
The router uses a single NAT translation table with 2 default routes
and some fancy load-balancing programming that puts half of the 
translation sessions on one default and the other half on the other
default.

 From the outside if the org is fielding servers internally, the
org publishes both IP numbers for the server forward - with the
caveat that if one of the DSL sessions goes down then connectivity
to the internal server is intermittent.  Obviously, you would have
severe problems fielding any kind of serious server behind such
a thing - like a DNS server for example.

NAT is an essential and required component of these schemes because
these routers are mainly load-balancing OUTBOUND requests for HTTP
traffic and suchlike.

These routers are cheap, generally under $200 or so.  The orgs that
deploy these solutions are generally very satisfied with them because
their primary purpose is failover, so that if one of their DSL lines 
goes down, they still can surf the web.  But their understanding of
failover is pretty much limited to that - when you tell them that an
upstream ISP of theirs could lose it's connectivity, yet their little
router wouldn't detect this, you generally get blank stares.

Trying to convince an org like you have described to toss out their
little sub $200 "load balancing" NAT/router and go to a real router that
costs 20 times more that can speak BGP is an exercise in futility.
They have a solution that gets them 90% of the way towards real
multihoming, is cheap, and does that 90% really well.  And most
importantly, they don't have to actually understand anything at all
about networking, they just plug it in and go.

Ted