On Dec 4, 2011 7:10 PM, "Chris Donley" <[email protected]> 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? 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. >
The ietf did act. It is called ipv6. And, they underscored that point by not rejecting various past attempts at expanding private ipv4 space like 240/4. Cb _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
