Re: [OPSAWG] Heads up - Plea for allocating a /8 to ISPs

Mark Smith <ipng-KJKIt35SYvig+96AiQNgT+hiC5znLf7cZPcaUtDxc8WOQDzvkKpvAmD2FQJk+8+b@public.gmane.org>
Newsgroups gmane.ietf.v6ops,gmane.ietf.ops
Message-ID <[email protected]>
On Mon, 15 Nov 2010 02:24:26 +1100
Christopher LILJENSTOLPE <[email protected]> wrote:

> Greetings,
> 
> 	It's a trade-off between slop in public address consumption by the CGNs and multiplication of services that need to be before the second nat (intercept comes to mind), and the desire to limit the impact of the request.
> 
> 	If, say, we had a small block, and needed to re-use it 16 times, then I would need 16 intercept infrastructures, and, more importantly, 16 public address pools (one for each CGN cluster, assuming one cluster to NAT444 "network").  That means that each of the public pools will have to have buffer, vs. sharing the buffer over fewer CGN clusters.
> 

So why should the global Internet miss out remaining IPv4 address
space, just because you want to avoid "16 intercept infrastructures"?
In your employer's market, your employer is large. On the world market,
your employer is small. Would your employer consider it fair if one of
the much larger global providers said, "we want all the available IPv4
address space for NAT444, to avoid "128 intercept infrastructures"?

I understand the specific issue of transitioning to IPv6 with customer
owned CPE. I don't however think it is fair that ISPs with this problem
to try to place opex and capex of dealing with it on the global
Internet community. These customers have participated in a market that
expects to be able to buy the CPE, from ISPs or other outlets. That
means that while they've benefited from price competition and choice,
they've also taken on some of the responsibility for the operational
costs of owning the CPE. Costs incurred due to software or hardware
upgrades, or costs incurred by their ISP dealing with them not
performing software or hardware upgrades when necessary, should be
borne by the people who've created and benefited from that market form
- the customers. As an ISP, that means passing on those increased capex
and opex costs onto to the customers themselves, not the global
Internet community.




> 	There is a bit of truth in what Randy says, although, not necessarily his intimation.  
> 
> 1) We want to use as small a block as reasonable without causing too many problems as identified above
> 2) By asking for a smaller block, we hoped to remove some of the emotion and heat from the discussion.  
> 
> 	Chris
> 
> On 13Nov2010, at 14.05, Sam Silvester wrote:
> 
> > On Fri, Nov 12, 2010 at 5:13 PM, Christopher LILJENSTOLPE
> > <[email protected]> wrote:
> >> It's not being used for internal devices, please re-read the draft.  It is
> >> to enable NAT444 to allow the delivery of IPv4 services, after run-out,
> >> using NAT444, to act as the v4 substrate between a CPE supporting 1918 to
> >> the customer, and the public internet.
> > 
> > I may have put that badly (Friday afternoon and all) in my original
> > reply - that's exactly what I meant. It seems (as has now been
> > commented on by a few) that a /10 seems like an awful mightly lot of
> > addresses to do this, considering this space would exist 'betwen' the
> > CPE and the CGN (I hate that term).
> > 
> > Can you speak as to where the decision was made for the 2^22 address
> > requirement & reasons why this couldn't be done with multiple
> > VRF-style instances of existing public IP address space?
> > 
> 
> ---
> 李柯睿
> Check my PGP key here:
> https://www.asgaard.org/~cdl/cdl.asc
> 
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.