Home page logo
/

nanog logo nanog mailing list archives

Re: IPv6 end user addressing
From: Owen DeLong <owen () delong com>
Date: Mon, 8 Aug 2011 10:09:08 -0700


On Aug 7, 2011, at 12:00 PM, Jeff Wheeler wrote:

On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <owen () delong com> wrote:
Well, you aren't actually doing this on your network today.  If you
practiced what you are preaching, you would not be carrying aggregate
routes to your tunnel broker gateways across your whole backbone.

Yes we would.

No, if you actually had a hierarchical addressing scheme, you would
issue tunnel broker customer /64s from the same aggregate prefix that
is used for their /48s.  You'd then summarize at your ABRs so the
entire POP need only inject one route for customer addressing into the
backbone.  Of course, this is not what you do today, and not because
of limited RIR allocation policies -- but because you simply did not
design your network with such route aggregation in mind.

You are, once again, conflating two related, but, not identical terms.

A hierarchical addressing scheme is NOT a hierarchical routing structure
and vice versa. Yes, a hierarchical routing scheme requires a hierarchical
addressing scheme, but, a hierarchical addressing scheme does NOT
require a hierarchical routing scheme.

We have a hierarchical addressing scheme. The fact that you dont' like
our idea of having two parallel hierarchies for two different addressing
structures is also getting in the way here.

For us, using parallel similar hierarchies for the /64 and /48 prefix blocks
works quite well and produces certain scaling advantages in our system.

As to the details of how our IGP works. I'm not going to debate that
with you because it is an internal matter and not really part of this
discussion. If you want to talk in the abstract about good ways to structure
routing, I'm happy to do that. However, it's a different (though related
as described above) subject from hierarchical addressing.

Those are artifacts of a small allocation (/32) from a prior RIR policy.
The fact that those things haven't worked out so well for us was one of
the motivations behind developing policy 2011-3.

There was nothing stopping you from using one /48 out of the /37s you
use to issue customer /48 networks for issuing the default /64 blocks
your tunnel broker hands out.


I was talking about the fact we were using /37s.

We have actually recognized significant advantages from using
different prefix blocks to assign /48s and /64s in the environment and
I don't expect us to change that practice even when we do get enough
address space to build out the hierarchy the way we want.

Those advantages, however, may well be unique to our tunnelbroker
structure and may not be applicable to other networks.

We give a minimum /48 per customer with the small exception that
customers who only want one subnet get a /64.

You assign a /64 by default.  Yes, customers can click a button and
get themselves a /48 instantly, but let's tell the truth when talking
about your current defaults -- customers are assigned a /64, not a
/48.


We assign a /64 by default only to tunnelbroker customers and to
customers without routers in our datacenters. I believe all others
default to a /48 per site.

I told the truth... We give a minimum /48 per customer with the small
exception that customers who only want one subnet get a /64. If you
didn't want only one subnet, presumably you would click the button
to get your instant /48.

We do have a hierarchical addressing plan. I said nothing about routing,
but, we certainly could implement hierarchical routing if we arrived at a
point where it was advantageous because we have designed for it.

How have you designed for it?  You already missed easy opportunities
to inject fewer routes into your backbone, simply by using different
aggregate prefixes for customer /64s vs /48s.


You are correct... With present hind-sight, we could have designed things
in such a way that we could have cut the number of aggregates to be
injected into the backbone from 50 to 25. Assuming that our network
doubles in size every year for the next 4 years, that would take us to
a total of 800 routes that could be 400. OTOH, since we get some other
advantages from this relatively small increment in prefixes, I think
we'll probably stick with the architecture we have for the advantages
it offers in other areas.

Reducing prefix count is not the only consideration in running a network.

However, requesting more than a /32 is perfectly reasonable. In
the ARIN region, policy 2011-3.

My read of that policy, and please correct me if I misunderstand, is
that it recognizes only a two-level hierarchy.  This would mean that
an ISP could use some bits to represent a geographic region, a POP, or
an aggregation router / address pool, but it does not grant them
justification to reserve bits for all these purposes.


While that's theoretically true, the combination of 25% minfree ,
nibble boundaries, and equal sized allocations for all POPs based
on your largest one allows for that in practical terms in most
circumstances.

I don't think it does allow for that.  I think it requires you to have
at least one "POP prefix" 75% full before you can get any additional
space from the RIR, where 75% full means routed to customers, not
reserved for aggregation router pools.  This is not a hierarchy, it is
simply a scheme to permit ISPs to bank on having at least one level of
summarization in their addressing and routing scheme.


No, it requires you to have 75% full over all or have at least one POP
that is 90% full. However, in this case, you can use POP to mean your
most distal aggregation point rather than something more proximal
to your core. The term in the policy is "serving site" and is defined
with sufficient flexibility to allow virtually any aggregation point to
be considered a "serving site".

Since you're allowed for a 5 year projection on your number of serving
sites, unless you have rather radical diversity in the sizes of your
upstream aggregations (this superpop serves 1000 pops, the other
one serves 3), I think you'll find that the math does, in fact, work out
OK.

2011-3 does not provide for an additional level to summarize on the
aggregation routers themselves.  It should, but my read is that the
authors have a very different opinion about what "hierarchical"
addressing means than I do.  It should provide for route aggregation
on both the ABR and the aggregation router itself.


Can you present an example of a network where this wouldn't work
out within policy? It can be fictitious and/or anonymous, but, show
me a setup where you think it doesn't work out well and I bet I can
show you how to work it. If not, I'll be the first to write an amendment.

As one of the authors, I have to say, I don't think our opinions of
what a "hierarchical" addressing plan means are all that different.
I think mine is perhaps a bit more flexible than yours, but, I wouldn't
say "radically different".

AT&T serves some entire states out of a single POP, as far as layer-3
termination is concerned.


Are any of the states with populations larger than Philadelphia among
them?

Yes, for example, Indiana.  Pretty much every state in the former
Ameritech service territory.

Philadelphia 1,526,006 (2010 census)
Indiana 6,4383,802 (2010 census)

OK.. just barely 4x, but, I would bet if you look at the definition
of the term serving site, Indiana would have smaller units than the
layer 3 termination physical address that would apply in Indiana.

Owen



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault