ietf
[Top] [All Lists]

RE: Consensus Call: draft-weil-shared-transition-space-request

2011-12-04 21:11:12

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?  Let's do the 
math here.  Consider a 10M subscriber ISP. Your breakage model (10%) 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?
 
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?  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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>