Re: IPv6 end user addressing

[Owen DeLong <owen () delong com>]

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