On 12/5/11 7:47 PM, "Doug Barton" <dougb(_at_)dougbarton(_dot_)us> wrote:
On 12/04/2011 19:10, Chris Donley wrote:
More seriously, the impression I've gathered from various discussions
is that the 90/10 model is viable, but it's not the first choice
because the 10 part involves customer service work that those
interested in deploying CGN would like to avoid in order to protect
their margins. I'm not sympathetic.
[CD] Really? 10% of customers having problems is a viable model?
I should have inserted the word "technically" in there to make my
meaning more clear. Sorry about the confusion.
Let's do the math here. Consider a 10M subscriber ISP. Your breakage
model (10%)
Please note, that's a total WAG. My gut is that the actual amount of
breakage will be substantially less, especially for an ISP that deals
primarily with the SOHO market.
So the word from the Service Provider community is that until someone can
prove that the level of breakage is sufficiently low, the risks associated
with the use of RFC1918 space are unacceptably high. I doubt many Service
Providers are willing to bet on your gut.
would generate at least 1 M support calls (some people
may call more than once). Let's say a support call costs $50 (I
don't know the exact cost, but I think this is close), so the cost of
supporting a 10% failure case will be close to the $50M you keep
quoting (multiply this by the number of affected ISPs). What do you
think an ISP will do if faced with this option and no Shared CGN
Space? Select an IETF-specified RFC1918 block of addresses and deal
with $50M of support costs plus 1M upset subscribers? Acquire
addresses from the RIR (or from an address broker)? Or squat on
someone else's space?
Thank you for confirming publicly that the issue here is not a technical
one, but rather that the ISPs would prefer not to bear the costs of
dealing with the problem that they helped create.
I don't know where to begin with this one. Of course this is a policy
discussion. IMO, it would be better resolved within the RIR community,
which is responsible for address policy. In fact, we did go to ARIN and
there was consensus to recommend Draft Policy 2011-5 to the ARIN Board.
However, the IAB instructed ARIN to seek IETF guidance before executing
2011-5, so here we are. Since this is a policy decision, the IETF
community gets to weigh in on how many addresses get reserved for CGN
space, and the technical/operational ramifications of such action. If we
reserve Shared CGN Space, the size of the block is 4 M addresses. If ISPs
acquire their own, the demand is somewhere around 30-40x that (at least in
the ARIN region) - a /10 is about 1 month's allocation. However, due to
imminent exhaustion, the amount of space that can be allocated for CGNs
before the free pool runs out is unclear, but somewhere between 4M and
150M addresses (again, within the ARIN region).
From a technical/operational perspective, I believe that Shared CGN Space
is preferable to an uncontrolled range such as public space or squat
space, as operators and equipment vendors can work around problems with
6to4 introduced by CGN. It is also preferable to Class E space, as many
pieces of equipment do not support 240/4. Finally, from an operational
perspective, it is preferable to RFC1918 space because it will not be in
conflict with existing customer addresses.
BTW, I think your $50M argument misses the mark. Since four of the five
RIRs still have address space available, ISPs can request addresses e.g.
From ARIN within their existing fee structure, provided they have
justification. Given the impending IPv4 exhaustion, I don't expect ISPs
will have a problem demonstrating need.
And if that doesn't fully answer your "Which part don't you agree
with?" question, I doubt that even a significant portion of ISPs are
going to use routable addresses internally for CGN as the value of
those addresses for their intended purpose is only going to increase,
and they will still need to be able to number publicly facing things
after the RIRs have exhausted their supply.
[CD] So you're really arguing for squat space?
Certainly not. I think I've made my position on the "right" way to
handle this issue perfectly clear.
I have a real problem
with that. I know people are already doing it, but I think it sets a
bad precedent and increases risk of interoperability problems across
the Internet. I believe the IETF has a vested interest in
discouraging address squatting, and should act accordingly.
If it's already being done then we've got "running code," right? :)
And some Chevy Volts have been known to ignite. Running code should not be
the only justification.
More seriously, it sounds to me like the most persuasive argument in
favor of doing the new allocation boils down to simple extortion. "Give
us a $50,000,000 'gift' or we'll do bad things to the intahrnetz."
Shared CGN Space is not a gift, and it's not extortion. It's a policy
discussion as to how best to manage the remaining IPv4 resources. ISPs
need (non-unique) addresses to go behind the CGN. They have stated that
for operational reasons, they won't use RFC1918 or 240/4 space. That
leaves three options:
A) Public space. Aggregate demand is somewhere around 150M addresses in
N. America, larger when you consider the rest of the world.
B) Shared CGN Space - a far smaller pool, shared amongst the ISPs, and
easiest of the three to fit into operations.
C) Squat Space
As to agency, we made this request to ARIN, the holder of the address
space, and the ARIN community reached consensus that this is an
appropriate use of IPv4 resources. We have a willing 'giver' and a group
of willing 'recipients', and we have clearly spelled out as best we can
the tradeoffs among the available options. IMO, Shared CGN Space is the
best of the available options for the reasons previously explained: it's
limited, it's defined, and it's (operationally) predictable.
Chris
Doug
--
[^L]
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf