In message <CAPWAtbJtPMDx-NzU8UphoSy+97ygo4Fknz5_eSghsjp-aN9x_A@mail.gmail.com> , Jeff Wheeler writes:
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. =A0If 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.
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.
So you want HE to force all their clients to renumber.
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.
The client can request a /48 or /64 as the initial allocation.
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.
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. =A0This 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.
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.
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.
--=20 Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator=A0 /=A0 Innovative Network Concepts
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org