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] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Michael.Dillon at radianz.com
Michael.Dillon at radianz.com
Thu Mar 31 12:45:59 CEST 2005
> > > 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. I don't know of any large carrier that operates a globally diverse network offering globally diverse hosting of the sort that these anycast meshes need. And I don't think we should be trying to create such things either. However, if we give a /32 to a company who will offer anycast services similar to the anycast services used by some root DNS servers, then we make it possible for TLD operators to buy the anycasting rather than forcing them to build their own. However, if you want to force them to build their own then you have to support giving every one of them their own /32. I think the world is better off if we encourage 3rd parties to build anycast meshes and offer them as a service to TLD operators and others. > 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. The idea is that anycasting is a solution for services which are "critical" and therefore they need independent address space. However, this could be provided by an anycast mesh operator who aggregates many networks and who offers an escrow agreement in their customer contracts to ensure continuity. Also, if RIPE enables several of these anycast meshes, I would expect that most TLD operators would use two or three independent anycast meshes. When you consider that they can easily use up to 13 IP addresses, it is easy to configure 3 addresses from 3 different anycast mesh operators, along with 10 diverse unicast addresses. > See: http://www.itu.int/ITU-T/worksem/ngn/200505/index.html I really don't see how the ITU is relevant here. This has nothing to do with them. It is all about Internet infrastructure and Internet addressing. --Michael Dillon
- Previous message (by thread): [address-policy-wg] Real multihoming or anycast?
- Next message (by thread): [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]