On Aug 6, 2011, at 1:14 PM, Jeff Wheeler wrote: > On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong <o...@delong.com> wrote: >> On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote: >>> Note that in this thread, you advocate three things that are a little >>> tough to make work together: >>> * hierarchical addressing plan / routing >>> * nibble-aligned addressing plan >>> * minimum /48 per customer >>> >> Hasn't been hard so far. > > 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. > Perhaps you also wouldn't use one allocation on the tunnel broker > gateway for /64s and another, a /37 in the case of Ashburn for > example, for users who self-provision a /48 from it. Also, of course, > your default assignment plan is /64, not /48, even though there are > typically around, what, 10k tunnels active network-wide? > 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. > To be clear, you don't do any of the three things you advocate above > where Hurricane Electric's tunnel broker service is concerned. > Yes we do. We give a minimum /48 per customer with the small exception that customers who only want one subnet get a /64. We will be implementing a nibble-aligned addressing plan as soon as we can get enough space from the RIR. That's pending implementation of 2011-3. 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. >> I think we were talking about access customers. I don't see giving /48s >> to individual dedicated servers as I don't see them having hierarchy >> behind them. I would think that a /48 per TOR switch would be >> reasonable in that case. > > I wish there was more discussion about IPv6 addressing plans in > hosting environments on this list. I think that, rarely, customers > will decide to tunnel from their home or office to their "dedicated > server," co-lo rack, etc. My addressing policies provide for this > type of customer to receive a /56 upon request without breaking my > hierarchical addressing scheme. If they need more than that, the > layer-3 aggregator has to inject an additional route into the POP > area. If a whole bunch of customers on one aggregator ask for /56, > then the aggregator needs an extra /48 (which might really mean > growing its existing /48 to a shorter route.) > Sounds like a mess. We'll stick with /48s for people that need more than a /64. >> 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. >> density, even in 20 years. I realize that customer density in >> urban areas does tend to increase, but, assuming a maximum >> 50% market penetration, serving a city the size of Philadelphia >> out of a single POP still seems unlikely to me. > > 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? Owen
smime.p7s
Description: S/MIME cryptographic signature