This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Real multihoming or anycast?
- Previous message (by thread): [address-policy-wg] Real multihoming or anycast?
- Next message (by thread): [address-policy-wg] Real multihoming or anycast?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Wed Mar 30 19:26:05 CEST 2005
On Wed, 2005-03-30 at 18:30 +0200, Andre Oppermann wrote: > Michael.Dillon at radianz.com wrote: > > > > > > Why not learn from the lessons of radio spectrum? A fixed number of > > > > 3G frequency allocations were put up for auction (or beauty contest). > > > > > > > > Why should RIPE not offer a limited number of /32 allocations for > > > > operators of anycast fabrics? I suggest that RIPE offer 16 allocations > > > > of /32 to organizations who intend to operate diverse anycast fabrics > > > > globally to serve TLD operators and others who can benefit from > > > > an anycast fabric. Select the winners by beauty contest based on > > > > technical and commercial fitness. > > > > > > Very simple answer for what is possible with _CURRENT_ policy: > > > $ whois -h whois.arin.net GOOGLE-IPV6 > > > > As far as I know, Google is not a service provider. Which is exactly my point. They don't serve the '200 customer rule'. They might have 200 anycast nodes though, but not disjunct organizations. Unless they reported every tld as a separate org ;) Akamai, who also got an alloc on the same day, might be easily able to claim it though. > They > > operate their own network for their own business. I am > > suggesting that a certain number of /32's should be given > > to companies which will provide global anycast meshes > > as a service to 3rd party customers. That way, TLD operators > > can choose one or more anycast hosting services to host > > their "critical" service. Thus you basically say that TLD operators should go to say, Easynet/Tiscali/Telia/$bigcarriers etc who already have IPv6 connectivity in place and ask them to give them a /48 out of their /32, they can do the carry service and presto? Sounds like a perfect plan, those carriers are already present, can fix their internal routing and usually also have perfect colo facilities in place. But..... this is already there, so why change policy? > > This makes more sense than giving a /32 to everyone who > > feels that their service is "critical". If you analyse the > > situation by the 80/20 rule, then Google represents the > > 20% of "critical" services that are big enough to be their > > own ISP. Every entity that is big enough can always buy themselves what they want, policy or not. > > My suggestion is meant to support the 80% of > > "critical" services that could benefit from the same > > technology as Google, but which are not large enough to > > go it alone. As mentioned above, let them request some address space from one of the larger carriers. Oh oops, there is one problem there, they actually wanted Independent Address Space, that is if they suddenly hate their upstream, it goes belly up etc that they don't have to change anything. Ergo sum they want a slot in the routing table and nothing else. > Sounds great! Do you work for ITU perhaps? > > Any such criteria as you propose are broken by design. Even more > so than many of the other IPv6 thingies. This is not the way to > go. I suspect Andre also to visit the upcoming (May 1+2) ITU/IETF NGN workshop in Geneva? :) See: http://www.itu.int/ITU-T/worksem/ngn/200505/index.html Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: </ripe/mail/archives/address-policy-wg/attachments/20050330/a81422d0/attachment.sig>
- Previous message (by thread): [address-policy-wg] Real multihoming or anycast?
- Next message (by thread): [address-policy-wg] Real multihoming or anycast?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]