In message <capwatbjtpmdx-nzu8uphosy+97ygo4fknz5_esghsjp-an9...@mail.gmail.com> , Jeff Wheeler writes: > On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong <o...@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 <j...@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: ma...@isc.org
