Subject: [RRG] Providers and providers

From: RJ Atkinson <[email-masked]>
Date: Wed, 20 Aug 2008 06:43:35 -0400

Let me point out what I previously thought had been
quite obvious --- though after browsing some recent
notes apparently is not obvious to all...

Large corporations that have large networks are ISPs.
They might be ISPs with themselves as the only customer,
but they are effectively the same as an ISP.

That's true for Boeing, for US DISA, and for probably
a few hundred other large (private) IP network operators.

Boeing doesn't have PI space.  oeing has PA space -- with
itself as its ISP.  Parts of Boeing *do* get renumbered
from time to time -- just as for DISA -- the IP address plan
of any large deployment or any large organisation simply
is never static.

The same basic analysis is true for US DoD networks,
which generally have DISA as their ISP.  DISA even
is funded on a "fee for service" basis, meaning that,
for example, USAF pays DISA to ensure IP connectivity
to each random AFB around the globe.

And by the way, while I think the US Government networks
are among the few "all continents" networks, I'm pretty
confident the USG isn't the largest ISP.  For one thing,
most of the civilian (and some of the DoD) IP connectivity
is supplied by commercial ISPs under GSA contracts
(e.g. Networx) that are remarkably similar to any other
customer contracts with the same big ISPs.  For example,
at one point DREN simply had been outsourced to AT&T.
US Navy outsourced a bunch of its domestic IP connectivity
via an EDS contract, if one believes Federal Computer Week
(a trade periodical).

The issue to hand before the broader community is not how
to deal with any really large network deployment.  The issue
is how to deal with the many many more mid-sized or smaller
deployments in some way that actually will scale in some
cost-effective manner.

Cheers,

Ran

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Aug 2008 15:49:33 +0200

> but they are effectively the same as an ISP.

Right.

So this isn't a problem. If the average fortune 500 company has 500  
offices in different locations and aggregates those 500 offices into a  
single PA prefix, we end up with 500 prefixes in the routing table.  
The trouble start when they don't act as an ISP and have each office  
connect to the internet independently - but they still want portable  
address space. In that case, we end up with 250k prefixes in the  
routing table.

But the bigger problem is what happens with smaller organizations. If  
a fortune 500 company can get X prefixes (where X = 1 or X = number of  
offices) then why wouldn't a smaller company be entitled to the same  
(relative) number of prefixes?

We used to have the requirement that you'd number 200 end-users out of  
your prefix to be able to get an IPv6 address block, but that was seen  
as unworkable for a large number of reasons, some of them even valid.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2008 15:58:46 +0200

Iljitsch,
> address space. In that case, we end up with 250k prefixes in the 

Huh?

First of all we're talking about announcements and not prefixes.  
Second, how many of those announcements are actually seen depends on the 
routing architecture.  In our current Bellman-Ford world, that would 
largely depend on the total number of inter-domain peers any given 
router has, right?

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Aug 2008 16:05:37 +0200

On 20 aug 2008, at 15:58, Eliot Lear wrote:

>> The trouble start when they don't act as an ISP and have each  
>> office connect to the internet independently - but they still want  
>> portable address space. In that case, we end up with 250k prefixes  
>> in the routing table.

> Second, how many of those announcements are actually seen depends on  
> the routing architecture.  In our current Bellman-Ford world, that  
> would largely depend on the total number of inter-domain peers any  
> given router has, right?

How does that make a difference?

If you get a single prefix but connect to the internet in 500  
locations, you need to deaggregate that prefix into 500 globally  
visible more specifics. This result is largely the same as the  
situation where you don't get that single prefix in the first place,  
but 500 individual ones.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2008 16:12:31 +0200

> situation where you don't get that single prefix in the first place, 

You said 250k, which is what got me.  500, yes.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Aug 2008 16:14:55 +0200

On 20 aug 2008, at 16:12, Eliot Lear wrote:

>> situation where you don't get that single prefix in the first  
>> place, but 500 individual ones.

> You said 250k, which is what got me.  500, yes.

Per organization with 500 offices. I was talking about the fortune  
500, so that would be 500 x 500 = 250000.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Aug 2008 10:16:32 -0400

On Aug 20, 2008, at 9:49 AM, Iljitsch van Beijnum wrote:

> offices in different locations and aggregates those 500 offices into  
> a single PA prefix, we end up with 500 prefixes in the routing  
> table. The trouble start when they don't act as an ISP and have each  

I don't get this math. I know of enterprises with N offices that have  
N address blocks, but the number
of prefixes grows as order (N) not order (N^2). Where does the order  
(N^2) come from ?

Regards
Marshall

> But the bigger problem is what happens with smaller organizations.  
> If a fortune 500 company can get X prefixes (where X = 1 or X =  
> number of offices) then why wouldn't a smaller company be entitled  
> to the same (relative) number of prefixes?
>
> We used to have the requirement that you'd number 200 end-users out  
> of your prefix to be able to get an IPv6 address block, but that was  
> seen as unworkable for a large number of reasons, some of them even  
> valid.
>
>
> --

---

From: Scott Brim <[email-masked]>
Date: Wed, 20 Aug 2008 10:17:31 -0400

On 8/20/08 9:49 AM, Iljitsch van Beijnum allegedly wrote:
> single PA prefix, we end up with 500 prefixes in the routing table. The
> trouble start when they don't act as an ISP and have each office connect
> to the internet independently - but they still want portable address
> space. In that case, we end up with 250k prefixes in the routing table.
> 
> But the bigger problem is what happens with smaller organizations. If a
> fortune 500 company can get X prefixes (where X = 1 or X = number of

True.

This problem arises when you simultaneously have resistance to
renumbering and routing information being propagated everywhere in
anticipation of use.  The various RRG proposals assume you can get rid
of one or the other.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 20 Aug 2008 10:25:26 -0400

> 500, so that would be 500 x 500 = 250000.

But, for better or worse, you already have those. Those companies have  
already done whatever they
are going to do, and will mostly make only incremental changes going  
forward.

By the way, my experience is that many large companies have most of  
their offices in their VPN, and so not
every remote office needs their own PI space. It is (in my experience)  
the remote offices that are effectively Autonomous Systems (e.g.,  
Singapore or Hong Kong for a US company).

Regards
Marshall

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 07:45:08 -0700

> Large corporations that have large networks are ISPs.

Please define 'large'.

Thanks,
-drc

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 20 Aug 2008 11:32:19 -0400 (EDT)

> From: David Conrad <[email-masked]>

    > Please define 'large'.

Perhaps your question is a rhetorical device, and you're merely trying to
point out that how to define 'large company' is a tarpit. For those who
really do need a definition of 'large', here are some thoughts.

Go back to the graph theory, which is what's underneath all this routing
stuff. For purposes of path selection computations, you need to indentify
nodes (and maybe arcs too, depending on your exact algorithm) in the graph.
For small graphs, you just number all the nodes, you're done. If it's a
really, really, really big graph, though, you can't do resource-feasible
computations if all you have is numbers for each distinct node.

In a very large graph, for purposes of path selection computations, you need
to select and name 'chunks' of the graph, and do path selection computations
for source-chunk / destination-chunk pairs; then you do further computations
for paths inside the chunks (and recurse, if necessary).

How many chunks is 'enough' and how many is 'too many'? It all depends on
lots of factors (e.g. how much memory/processing/bandwidth overhead you want
your path computations to consume, how efficient you want the paths to be,
etc, etc).

Anyway, once you've decided how big your top-level 'chunks' are going to be,
a corporation whose network has that many nodes is 'large', and gets its own
top-level 'chunk' identifier (aka PI locators); companies smaller than that
do not.

Put it another way, if you decide the DFZ can handle E entries, and the
total size of the network is N nodes, if a company has more than N/E nodes,
it gets PI locators, and if it has less than N/E, it doesn't.

	Noel

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 10:46:28 -0700

On Aug 20, 2008, at 8:32 AM, Noel Chiappa wrote:
> point out that how to define 'large company' is a tarpit.

Yep.  However, a more general point as any attempt to create an  
architecture that depends on some subjective term like 'large' is  
doomed to fail.  Since there is benefit from having connectivity/ 
provider independent addresses, there will always be pressure to  
liberalize the allocation policy, resulting in the exact same mess  
we're in now (if you'll remember, the original IPv6 allocation plan  
was to limit the total number of "top-level aggregators" to 8192).

And, of course, whether an organization is 'large' is irrelevant when  
it comes to whether or not the addresses for that organization are  
multi-homed.

Regards,
-drc

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 20 Aug 2008 14:02:52 -0400

Folks,

   My comment was mostly noting something that has already
been happening via existing registry policies.  Some firms/
organisations that have only themselves (or their parent
and its components) as customers have obtained PA address
blocks on the basis that they are an ISP.

   That ship sailed and the precedent was set, long ago,
and even happened some while back in the case of IPv6.

   In one sense, no registry policy change seems to be
required for this, since the approach has been used
successfully several times now.

Cheers,

Ran
[email-masked]

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 20 Aug 2008 14:12:06 -0400 (EDT)

> any attempt to create an architecture that depends on some subjective
    > term like 'large' is doomed to fail.

Well, I did provide a very specific formal definition of 'large enough to
get their own chunk of top-level location namespace':

    >> if you decide the DFZ can handle E entries, and the total size of the
    >> network is N nodes, if a company has more than N/E nodes, it gets PI
    >> locators, and if it has less than N/E, it doesn't

But there is still your other point:

    > there will always be pressure to liberalize the allocation policy,
    > resulting in the exact same mess we're in now

which I completely agree with. The problem is that there's always going to be
a gray area in terms of what an acceptable top-level 'chunk' size is, i.e.
how big E can be:

    >> It all depends on lots of factors (e.g. how much
    >> memory/processing/bandwidth overhead you want your path computations to
    >> consume, how efficient you want the paths to be, etc, etc).

In a network with 10^12 nodes, having 10^2 top-level 'chunks' is trivial, and
having 10^10 is definitely not workable. But do you decide to set it at 10^5,
or 10^6, or where? So instead of the fight being about 'is my organization
big enough', it will simply turn into 'why don't you set E large enough so
that my organization qualifies'.

Ultimately, it's a resource allocation question, and the best answer we've
ever discovered to allocating resources is a market, with pricing. However,
there's still resistance to doing that.

Have any providers made public statements about how small a prefix they will
route? I know in the past there have been some on the v4 side, but has anyone
said anything about v6?	Presumbably they won't route /128's, but has anyone
made explicit what their policy will be?

You can view such filtering as a simplistic price function: below size X,
cost is infinite, above it, it's free...

if one large ISP steps up and says 'we won't route blocks below size X',
where X is a lot larger than most PI blocks, all of a sudden PI blocks won't
look so attractive any more...

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Aug 2008 09:56:56 +1200

On 2008-08-21 03:32, Noel Chiappa wrote:
...
> it gets PI locators, and if it has less than N/E, it doesn't.

Of course, this has the same chance of being accepted as registry
policy as I do of running faster than Usain Bolt. But it points us
once again to the fact that user sites do not pay the correct
price for their externality costs. As we've known for many years,
an appropriate economic model would be for ISPs to be charged per
BGP route that they advertise, and to pass these costs on to user
sites proportionately.

By the way, I showed a graphical history of E against sqrt(N) in
the IEPG meeting in Dublin (slide 8 in
http://www.iepg.org/2008-07-iepg72/carpenter.pdf ). I'm working
on a writeup.

    Brian