[address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
- Previous message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
- Next message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Joao Damas
Joao_Damas at isc.org
Tue Jun 15 12:19:32 CEST 2004
Gert, On 15 Jun, 2004, at 11:46, Gert Doering wrote: > Hi, > > as the discussion seems to have ebbed down, let me try to summarize. > Please correct me if this isn't fully correct. > > There have been a few comments about wording, to make the criteria > more precise. > > There has been some confusion on whether this is "PI". It is not, it's > "anycast space", and should be tagged as such in the database, to help > people recognizing these special blocks immediately as such. The usual > rules apply: "if the criteria for allocations do no longer apply, the > address block should be returned" (even if that is unlikely to happen > very often in practice). > Don;t know if there is a real need to tag things like this in the DB, but I am not going to argue either way. > There has been the question whether an operator can only get one > prefix, or multiple prefixes. I have amended the proposal to > include the option for multiple prefixes, but also point out that > the usual thing will be "only one (set)" Good up to here. > . This is meant as kind of > guidance - "deploy one set, and if that's well understood and > you want to deploy another set, feel free to come back". the "come back" part spoils it. Some people already understand this pretty well, no need for a several step ballet. > > Along that lines, there has been some confusion about redundancy. An > important clarification is that it's not expected to put *all* > nameservers > into the (single) anycast prefix, but have "unicast" servers and one > (or "few") anycast sets. So if the anycast prefix is unavailable from > some networks, clients will fall back to one of the unicast servers. > This could be the subject for a BCP sort of document by the DNS wg, but it has no place in an IP allocation policy. > There has been a question on whether "end users" can directly request > anycast address space, and the suggestion is that it should be handled > the same way as PI space and AS space: the request needs to be passed > through an existing LIR. > Cool. > One comment asked for "do we really need yet another special rule > here", > and my reply would be "the current PA and PI policy doesn't permit > doing > this without lying to the NCC", *and* DNS is really special here due to > protocol constraints. > There is need for a new rule because the current policy does not support the deployment of a well known and accepted operational setup that addresses a specific problem. I don't know about "special". > > To my understanding, there were no real fundamental objections, though > (besides, this proposal was already discussed on the list and in the > APWG meeting at R47, with mostly neutral-to-positive reactions) > > > So based on these comments, I want to suggest the following new > text, to be incorporated into the policy documents: > > ------------ snip ------------ > "Operators providing DNS for a zone served by a number of name servers > such that the total response size when including the list of > nameservers for the zone is close to the UDP packet size limit may > be assigned dedicated network prefixes for the sole purpose of > anycasting name servers, as described on RFC 3258. These shall be: > a /24 IPv4 prefix and/or a /32 IPv6 prefix per anycast server set, > which will usually only be one per operator. The prefixes shall be > tagged as 'ASSIGNED ANYCAST' in the RIPE database and should be > returned to the RIPE NCC if not in use for anycast DNS any longer." > ------------ snip ------------ I support your suggested wording. > > > To be able to proceed with the implementation, let's set a deadline > of July 13 (4 weeks from now). If no fundamental opposition is voiced, > we can call it consensus, and ask the RIPE NCC to go ahead with it. > Joao
- Previous message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
- Next message (by thread): [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]